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1.   INTRODUCTION 

At  present,  the  various  departments  of  the  University  of  Illinois 
(UI)  manually  maintain  student  records.  Courses—scheduled,  in  progress, 
and  completed—and  grades  received  are  typically  recorded  on  a  form  like  the 
one  shown  in  Figures  1  and  2,  used  by  the  Department  of  Computer  Science. 
Faculty  members  (advisors)  who  help  plan  students'  programs  use  the  infor- 
mation on  these  forms  to  arrive  at  their  recommendations  for  future  course- 
work. 

The  advisor's  duties  are  complicated  by  several  considerations. 
Often  he  must  counsel  students  in  different  curricula;  occasionally,  as  in 
the  Department  of  Computer  Science,  these  curricula  reside  in  different 
colleges.  A  student  is  allowed  to  meet  either  current  requirements  or  the 
requirements  which  were  in  effect  when  he  entered  his  curriculum— whichever 
are  least  stringent.  The  amount  of  information  with  which  an  advisor  must 
be  familiar  is  clearly  large. 

To  lighten  the  burden  on  the  advisor,  it  would  be  advantageous  to 
automate  this  information  retrieval  and  data  processing  system.  A  prototype 
on-line  filing  (0LF)  program  package  has  been  written  to  provide  the  frame- 
work for  such  a  system. 

Viewed  in  its  simplest  form,  0LF  is  a  program  which  retrieves  an 
existing  student  record.  It  is  designed  to  allow  secure  and  easy  interaction 
with  subroutines— data  processors— requiring  different  access  rights  (to  both 
data  files  and  to  other  processors)  and  search  strategies  (all  students, 
students  of  one  department,  etc.).  Some  of  the  functions  necessary  for  a 
complete  system  include  file  insertion/deletion,  program  approval  (prerequisite 
checking),  and  grade  point  average  (GPA)  calculation.  By  incorporating 
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Figure  1.  Graduation  Requirements  Form-- 

Department  of  Computer  Science  (Side  1) 


MATHEMATICS  AND  COMPUTER  SCIENCE  CURRICULUM 
Notes  on  Graduation  Requirements  Form 

Transfers: 

Enter,  in  the  appropriate  section,  the  number  of  hours  credit  together 
with  a  T  for  grade  for  all  courses  transferred  onto  the  student's  record. 

A:   The  courses  marked  on  the  form  are  requirements,  where  a  /  indicates  an 
alternative  and  courses  in  parentheses,  if  taken  before  entry  to  the  cur- 
riculum, are  alternatives  to  the  immediately  preceding  course  on  the  left, 

Dl:  Four  semesters  of  P.E.  required,  no  credit  hours. 

D3:  Entrance  to  the  four  course  sequence  in  a  single  foreign  language  may  be 
made  at  a  point  determined  by  a  proficiency  examination,  and  the  first 
course  taken  may  be  for  0  credit. 


D4,  D5,  D6:  Refer  to  LAS  Student  Handbook,  1969-70,  pp.  8-9. 


Advanced  Courses: 

The  requirement  of  30  hours  in  advanced  courses  is  automatically  satisfied 
by  the  addition  of  1  more  200  or  300  level  course. 

Completed  Requirements: 

As  requirements  for  each  section  are  completed,  check  (•)  the  appropriate 
"completion"  square  and  enter  the  number  of  hours  of  credit  gained  in  that 
section.  Indications  of  the  minimum  credit  requirements  are  shown  in 
parentheses. 

Comments: 

Requirement  Dl  is  no  longer  in  effect. 


Figure  2.  Graduation  Requirements  Form-- 

Department  of  Computer  Science  (Side  2) 


write-protection,  search  control,  and  I/O  management  within  0LF,  it  becomes 
safe  to  allow  users  to  write  processors.  0LF,  therefore,  makes  possible  the 
compilation  of  many  presently  unavailable  statistics. 

The  0LF  system  and  a  GPA  calculator,  file  insertion/deletion  proces- 
sors, and  a  sample  statistics  processor  designed  to  use  0LF  are  discussed 
below. 


2.   SYSTEM  CONSIDERATIONS 

PL0RTS,  the  filing,  remote  job  entry,  and  timesharing  facility  of 
the  UI  uses  an  IBM  360/75  interfaced  to  teletype  (TTY)  and  IBM  2741  terminals 
through  a  PDP-7.  PL0RTS  files  are  maintained  on  magnetic  discs.  Interactive 
jobs  are  limited  to  100K  bytes  of  main  memory.  If  several  users  try  con- 
currently to  use  a  single  file,  a  copy  is  loaded  into  core  storage  for  each. 
The  PL0RTS  monitor  prevents  one  user  from  overwriting  a  file  being  read  by 
another  user. 

At  present,  BASIC  and  F0RTRAN  are  supported  in  their  CALL/36O-0S 
implementations  (with  a  few  minor  changes  to  follow  the  conventions  of 
PL0RTS).  0LF  has  been  programmed  in  F0RTRAN  because  of  the  inferior  character- 
manipulation  features  of  CALL/36O-0S  BASIC. 

Access  to  PL0RTS  requires  knowledge  of  two  items:  a  valid  PL0RTS 
problem  specification  number  (PS#)  used  for  accounting  purposes  and  a  name 
recognized  as  that  of  a  user  under  that  PS#.  PL0RTS  files  form  a  tree  as  shown 
in  Figure  3.  A  complete  name  has  the  form 

PS# . username . level  1  name. level 2name levellastname 

where  each  level  name  is  a  character  string  of  eight  or  fewer  EBCDIC  charac- 
ters (exclusive  of  blank,  comma,  or  period).  File  names  created  within  a  pro- 
gram can  contain  "characters"  which  are  not  available  on  a  terminal;  any  such 
name  can  then  be  accessed  only  by  a  program.  In  order  that  a  file  be  acces- 
sible by  program,  the  part  of  its  name  corresponding  to  the  underlined  por- 
tion of  the  general  form  above  cannot  exceed  eight  characters.  The  more 
qualified  (the  more  levels  to)  a  file's  name,  the  greater  the  access  time  for 
the  file. 

A  PL0RTS  user  is  given  full  access  (read/write/execute  privileges) 
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only  to  the  branch  of  the  tree  named  by  the  PS#  and  name  with  which  he  logged 
in.  (To  access  a  file  farther  down  on  that  branch,  he  need  specify  only  the 
remaining  part  of  its  name.)  He  can  read  (copy)  another  user's  file  if  he 
knows  the  complete  file  name.  This  is  the  basic  PL0RTS  security  arrangement. 

Execution  of  TSBATCH,  a  catalogued  procedure  in  the  batch  proces- 
sing system,  makes  card  image  input  appear  to  the  PL0RTS  monitor  to  be  a 
PL0RTS  terminal.  This  has  three  advantages.  First,  large  amounts  of  input 
can  be  fed  to  an  "interactive"  program  through  the  card  reader  (any  mis- 
punched  information—hopefully  a  small  subset  of  the  original  data—can  then 
be  resubmitted  in  true  interactive  mode).  Second,  a  PL0RTS  program  can  be 
run  as  one  job  step  of  a  longer  batch  job.  Third,  PL0RTS  can  be  used  even 
when  the  PDP-7  is  not  available. 

Each  PL0RTS  file  is  composed  of  blocks.  A  block  contains,  besides 
information  for  the  monitor,  eight  or  more  card  images  (varying  because 
trailing  blanks  are  suppressed).  Files  can  be  created  either  by  the  terminal 
command  0PEN,  or,  during  program  execution,  by  invoking  for  output  the  sub- 
routine 0PEN.  One  block  is  allocated  to  a  file  when  it  is  created;  additional 
blocks  are  automatically  added  as  needed. 

Unfortunately,  files  can  be  deallocated  only  by  the  terminal  command 
destroy  (DEST).  However,  a  program  can  lose  all  information  in  a  file  without 
deallocating  its  disc  space  by  opening  the  file  for  output.  (If  the  file  has 
multiple  blocks,  this  maneuver  will  reduce  to  one  the  number  of  blocks  allo- 
cated.) An  executing  job  can,  however,  write  onto  disc  the  card  image  of  a 
DEST  command  for  each  obsolete  file.  A  TSBATCH  job  can  then  use  these  records 
to  perform  the  file  deallocation. 

As  mentioned,  PL0RTS  files  are  kept  on  magnetic  discs.  Programs  are 
swapped  between  main  memory  and  disc  during  execution.  Data  files  appear 
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sequential  to  executing  programs.  In  this  environment,  program  structure  is 
optimized  with  respect  to  response  time  by: 

1)  minimizing  the  number  of  file  accesses; 

2)  manipulating  files  in  core  storage  whenever  possible 
(so  that  access  of  file  items  is  direct); 

3)  compacting  the  program  to  minimize  the  time  spent 
waiting  for  main  memory  to  become  available  for  reloading. 

The  methods  used  in  0LF  to  implement  these  goals  are  discussed  below. 


3.   SEARCH  STRATEGY  &  FILE  STRUCTURE 

3.1  Basic  Search  Methods 

A  program  can  locate,  or  determine  the  absence  of,  a  student's  file 
by  generating  the  appropriate  file  name  and  invoking  for  input  the  0PEN  sub- 
routine. If,  upon  return,  the  error  flag  is  set,  the  file  is  absent;  other- 
wise the  file  has  been  successfully  accessed. 

The  single  search  strategy  possible  using  this  method  requires 
naming  each  file  individually.  An  attempt  to  compile  university-wide  statis- 
tics would  require  approximately  30,000  such  specifications.  A  prepared  list 
of  students  would  make  group  access  feasible,  but  preparation  of  a  student  list 
for  each  group  (e.g.,  each  college  and  curriculum)  likely  to  be  accessed 
collectively  would  entail  an  inordinate  amount  of  effort  and  replication. 

A  tree  structure  (e.g.,  Figure  3)  allows  use  of  a  family  of  search 
strategies.  Within  a  tree,  a  member  is  uniquely  defined  by  the  concatenation 
of  the  name  of  the  leaf  with  the  names  of  all  nodes  leading  to  the  leaf.  More 
pertinent  to  this  discussion,  a  set  of  members  can  often  be  selected  by  naming 
one  node  common  to  the  set--the  root  of  a  subtree.  A  tree  designed  with 
thought  towards  probable  access  classes  will  most  often  be  searched  by  tracing 
only  selected  subtrees. 

3.2  The  0LF  Tree 

0LF  student  files  are  accessed  through  the  tree  shown  in  Figure  4. 
A  node  is  implemented  as  a  directory  (list)  of  its  immediate  branches.  Both 
student  files  and  directory  files  of  all  levels  are  found  in  the  top  level  of 
the  PL0RTS  tree,  as  shown  in  Figure  5.  Each  0LF  file  exists  independently  on 
disc. 

Each  directory  file  consists  of  an  INTEGER*4  length  field  and  a 
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REAL*8  vector.  The  meaning  of  each  component  depends  upon  the  directory  level 
Figure  6  further  illustrates  the  directory  structure. 

The  single  level -one  directory  lists  all  curricula  whose  students 
have  0LF  files.  Each  element  of  the  vector  holds  the  name  of  a  level -two 
directory  file,  formed  from  a  numeric  curriculum  code.  The  file  names  are 
kept  in  ascending  order.  The  value  of  the  length  field  equals  the  number  of 
curricula  listed. 

Each  level-two  directory  stores  the  complete  list  of  undergraduate 
advisors  for  the  curriculum  after  which  the  file  is  named.  Elements  in  the 
first  half  of  the  vector  contain  the  names,  truncated  to  eight  letters,  of 
the  advisors  in  alphabetic  order.  Each  advisor's  name  has  as  an  associated 
entry  in  the  second  half  of  the  file,  the  name  (obtained  from  the  advisor's 
social  security  number)  of  a  level -three  directory  file.  These  associated 
elements  have  as  a  group  the  same  relative  positions  in  the  bottom  half  of 
the  vector  as  do  the  alphabetized  names  in  the  top  half.  The  length  field  has 
as  its  value  the  number  of  advisor  names  (which  equals  the  number  of  level- 
three  file  names)  listed. 

Each  level-three  directory  holds  the  list  of  all  students  (advisees) 
of  the  advisor  after  whom  the  file  is  named.  Each  vector  element  stores  the 
name  of  one  student's  file,  formed  from  his  social  security  number.  The  file 
names  are  kept  in  ascending  order.  The  value  of  the  length  field  indicates 
the  total  number  of  advisees  of  an  advisor,  even  if  the  advisor  counsels  for 
several  curricula  (see  Search  Strategies,  below). 

The  major  components  of  the  student  file  are  the  header  (identifi- 
cation), the  general  information  block  (GPA,  hours  towards  degree,  etc.),  the 
requirements  check-off  list,  and  the  course  history  block.  A  more  detailed 
description  accompanies  Figure  7. 
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(a).     0LF  Directories  as  Stored  on  Disc 


The  conventions  for  file  names  are  explained  in 
the  section  File  Names. 
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Figure  7.     The  Student  File 
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The  design  of  the  student  file  is  complicated  by  the  goal  of  allowing 
for  user-supplied  processors  with  unknown  data  requirements.  A  small  amount  of 
unassigned  space  is  included  in  the  file  to  be  defined  as  necessary.  It  is 
expected  that  the  information  which  is  currently  found  in  the  file  will  be 
adequate  for  most  purposes. 

3.3  File  Names 

A  complete  advisory  and  record  keeping  system  requires  student  data 
files,  directories,  course  description  tables,  and  requirements  tables  for 
curricula  and  colleges.  A  consistent  naming  convention  is  needed  to  avoid 
duplication  of  file  names.  A  convenient  feature  (but  see  section  on  SAFETY 
&  SECURITY,  below)  is  direct  accessibility  from  the  terminal. 

3.3.1  Student  Files 

UI  identifies  its  students  by  social  security  number  (SSN).  The 

eight  character  limit  for  program-accessible  PL0RTS  file  names  precludes 

direct  use  of  nine  digit  SSNs  as  identifiers.  The  following  algorithm  is 

used: 

The  SSN,  interpreted  as  a  nine  digit  decimal  number, 
is  converted  to  an  eight  digit  hexadecimal  number. 
Each  hexadecimal  digit  is  stored  in  character  repre- 
sentation in  a  separate  byte  of  a  REAL*8  variable. 
This  character  string  consists  entirely  of  characters 
available  on  the  terminal  and  contains  no  characters 
that  are  invalid  (or  undesirable,  like  period)  in 
PL0RTS  file  names. 

Student  files  are  on  level  4  of  the  0LF  tree. 
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3.3.2  Directory  Files 

The  single  level-one  directory  file  is  the  master  curriculum  list 
named  CURRIC. 

The  name  of  each  level-two  file  is  derived  from  a  six-digit  college/ 
curriculum  code.  The  two  leftmost  digits  indicate  the  college  and  the  re- 
maining four  digits  identify  the  curriculum  within  the  college;  curriculum 
codes  shorter  than  four  digits  must  be  extended  to  four  digits  by  adding  non- 
significant zeroes.  A  basis  for  all  of  a  curriculum's  file  names  is  formed  by 
storing  these  digits  in  character  form  left-justified  in  a  REAL*8  variable. 
(No  decimal  to  hexadecimal  conversion  is  required  since  the  code  is  only  six 
digits  long.)  The  directory  name  for  the  curriculum  is  generated  by  right- 
justifying  these  six  digits  in  another  REAL*8  variable  and  inserting  $$  into 
the  two  vacant  high-order  bytes.  Other  files  for  this  curriculum,  if  needed, 
can  be  named  by  using  other  (non-alphanumeric)  characters  in  place  of  $$.  A 
level-two  file  named  $$220014  contains  the  advisor  list  of  curriculum  14  of 
college  22. 

The  name  of  each  level -three  file  is  generated  from  an  advisor's  SSN. 
It  is  convenient  (see  PROCESSORS)  that  level-three  file  names  be  distinguish- 
able from  level -four  file  names,  also  generated  from  SSNs. 

Nine  digit  SSNs  are  bounded  by 

0  <  SSN  <  109-1 
while  the  range  for  a  positive  FORTRAN  full  word  integer  K  is 

0  <  K  <  2*109  . 

Q 

Adding  10  to  an  advisor's  SSN  yields  a  ten  digit  "SSN"  which  is  convertible  to 
a  file  name  by  the  algorithm  used  for  level -four  file  names,  but  which  is 
easily  identified  as  being  a  level -three  file  name. 
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3.3.3  Other  Files 

A  complete  system  requires  various  curriculum,  department,  and 
college  tables.  A  basis  for  curriculum  file  names  is  discussed  above.  Differ- 
erent  curriculum  files  resemble  level -two  directory  file  names  with  $$  replaced 
by  other  characters. 

College  files  can  be  similarly  formed:  **22  might  be  the  name  of 
the  requirements  file  of  college  22. 

Department  files  can  be  formed  from  the  standard  UI  department  name 
abbreviations.  Since  these  consist  of  five  or  fewer  letters,  names  for  sev- 
eral departmental  files  can  be  generated  by  addition  of  special  characters. 

A  few  files  like  CURRIC  (all  are  listed  in  the  appendices)  have  pre- 
determined alphabetic  names. 

3.4  Search  Strategies 

Every  record  search  requires  a  set  of  search  limits.  (The  implicit 
limit  in  searching  an  unstructured  file  collection  is  the  collection  size, 
although  the  search,  if  successful,  may  not  reach  this  limit.)  The  natural 
search  limit  in  a  tree-organized  record  set  is  the  last  common  node--the  root 
of  the  smallest  subtree  which  includes  all  members  of  the  search  class. 

The  four  natural  classes  in  the  0LF  tree  are:  all  students,  all 
students  within  a  single  curriculum,  all  students  of  a  common  advisor,  and  an 
individual  student.  They  correspond,  respectively,  to  last  common  nodes  at 
levels  one,  two,  three,  and  four.  0LF  uses  all  four  access  classes. 

A  small  amount  of  interconnection  (not  shown  on  previous  figures) 
exists  between  directory  branches.  An  advisor's  node  is  attached  to  the  nodes 
of  all  curricula  in  which  he  advises.  Some  advisor  files,  and  hence  some 
student  files,  might  therefore  (see  Figure  8)  be  accessible  by  several  paths. 
The  curriculum  entry  in  the  general  information  block  of  a  student's  file  is 
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compared  to  the  current  level -two  search  node  to  avoid  extraneous  or  redundant 
processing.  Thus,  while  0LF  files  are  not  organized  in  a  true  tree  (as  de- 
fined above),  a  simple  procedure  renders  the  difference  inconsequential. 

Each  search  need  not  be  specified  from  the  level -one  node.  Pre- 
viously specified  nodes  are  defaulted  subject  to  the  conventions  that: 

1)  in  any  access  mode,  nodes  beneath  the  level  of  access 
become  undefined  at  the  completion  of  the  search; 

2)  all  nodes  past  a  changed  node  must  be  redefined; 

3)  whenever  a  new  processor  is  selected,  a  new  search 
strategy  must  be  defined  starting  from  the  level-one 
node. 

A  program  can  access  any  file  directly  (without  using  the  0LF  tree), 
if  its  name  is  known,  by  invoking  the  subroutine  OPEN.  This  is  not  the  in- 
tended 0LF  access  mode,  and  is  used  in  only  one  instance  (see  PROCESSORS). 

The  0LF  tree  helps  realize  the  three  response-optimizing  goals  set 
in  SYSTEM  CONSIDERATIONS:  minimal  file  accessing,  editable-in-core  files, 
and  a  compact  load  module. 

Batch-access  of  student  files  is  implemented  through  systematic 
progression  along  the  tree.  One  or  more  (depending  on  the  access  level) 
directories  (where  a  directory  is  the  internal  representation  of  a  node)  is 
referenced  repeatedly.  In  individual  access  mode,  it  is  not  unlikely  that 
files  of  a  common  advisor  will  be  processed  sequentially.  One  directory  of 
each  level  is  therefore  kept  in  main  memory,  and  a  new  directory  is  loaded  only 
when  necessary.  Since  there  is  a  single  level-one  file  (CURRIC)  only  levels- 
two  and  -three  directories  are  ever  replaced. 

Like  the  directory  files,  the  student  file  has  a  compact  organiza- 
tion. In  the  prototype  design,  three  directories  occupy  2092  bytes  while  a 
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student  file  fills  1648  bytes.  These  requirements,  less  than  4K  bytes  com- 
bined, are  an  acceptable  fraction  of  the  100K  allowed  to  PL0RTS  programs. 
Keeping  these  files  in  main  memory  allows  direct  access  of  file  items,  with- 
out jeopardizing  the  compactness  of  the  load  module. 

Figure  9  shows  the  internal  representation  of  the  pointer  system 
used  in  tree  access. 
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Figure  9.     Tree  Pointers 
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4.   PROCESSORS 

0LF  does  not  itself  manipulate  any  of  the  information  within  indi- 
vidual student  files:  this  is  the  job  of  data  processing  subroutines,  here- 
after called  processors,  which  operate  within  0LF.  Each  new  processor  can 
use  previously-written  processors  as  subprocessors.  A  processor  that  adds 
transfer  students  to  0LF  can  be  constructed  from  a  file  creation  processor, 
a  program  recording  processor,  and  a  credit  assignment  processor  (which  in 
turn  would  invoke  a  GPA  calculating  processor). 

4.1  The  Processor  Interface 

At  the  interface  between  0LF  and  the  processors  are  the  terminal 
input  buffer  and  the  processor  access  rights  table  (PART),  shown  in  Figure  10. 
The  regulated  rights  are  student  file  I/O,  directory  file  output,  and  direct 
access  of  student  files.  Access  of .  one  processor  by  another  is  restricted  in 
only  two  ways:  the  subprocessor's  file  I/O  rights  must  be  a  subset  of  the 
rights  of  its  invoking  processor,  and  no  processor  can  be  invoked,  directly  or 
indirectly,  by  itself.  The  latter  restriction  is  inherent  to  FORTRAN;  the 
reasons  for  the  former  restriction  should  become  apparent  in  light  of  the  dis- 
cussion below. 

A  necessary  condition  to  guarantee  that  all  instructions  intended 
for  0LF  are  properly  received  is  the  denial  of  terminal  input  to  the  proces- 
sors. The  terminal  is,  unfortunately,  unconditionally  available  to  all  PL0RTS 
programs.  After  reading  enough  information  to  define  a  search  strategy,  0LF 
rewrites  on  disc  all  terminal  input  until  a  blank  line  is  submitted.  (If  in- 
put is  via  the  card  reader,  the  first  card  image  not  in  data  format  causes 
buffering  to  terminate.  This  card  image  is  used--after  return  from  the  active 
processor—as  the  next  command  to  0LF.)  The  processors  are  supposed  to  read 
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The  processors  named  above  are  described  in  the  section  Sample  Processors 

Student  File  Input  Limit:  0   ".cad  header,  general  information  block 

1:  Read  entire  student  file 
Student  File  Output 
Authorization: 


Directory-Editing 
Authorization: 

Direct  Access 
Authorization: 

Extra  Access 
Authorization: 


0:  Not  allowed  to  rewrite  file 

1:  Allowed  to  rewrite  file 

0:  Not  allowed  to  edit  directory 

1:  Allowed  to  edit  directory 

0:  Tree  access  only 

1:  Direct  (non-tree)  access  allowed 

0:  Invoke  processor  once  per  student  file 

1:  Invoke  processor  once  per  student  file 
plus  once  at  completion  of  batch  access 


Figure  10.  Processor  Access  Rights  Table  (PART) 
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from  the  buffer,  but  this  policy  cannot  be  enforced.  A  multi-step  processor 
can  read  an  input  stream  repeatedly  by  rewinding  the  sequential  disc  data 
set.  If  necessary,  the  input  stream  can  be  edited  for  the  use  of  sub- 
processors. 

A  file  is  edited  by  writing  an  altered  version  of  the  file  over  the 
original  contents.  Write  protection  for  0LF  files  is  implemented  through 
control  of  file  output.  File  access  is  restricted  to  0LF  since  file  names  are 
kept  secret  from  the  processors.  0LF  will  not  copy  a  file  back  onto  disc 
unless  the  initiating  processor  has  student  file  output  authority  in  PART. 
All  processors  return  completion  codes;  0LF  does  not  rewrite  the  current  stu- 
dent file--even  if  the  active  processor  has  write  authority—if  the  last  com- 
pletion code  indicates  a  processing  error. 

Certain  processors  may  use  only  information  found  near  the  beginning 
of  student  records.  The  student  file  input  parameter  in  PART  controls  the 
amount  of  data  read  from  each. record.  (The  time  saved  by  a  partial  read-in  is 
less  than  might  be  expected--the  buffer  assigned  by  the  PL0RTS  monitor  to  the 
disc  controller  is  larger  than  a  complete  student  file.)  Rewriting  of  a  par- 
tially loaded  file  causes  erasure  of  the  unread  portion  of  the  file;  there- 
fore all  editing  processors  (except  DELETE  FILE)  must  read  entire  files. 

0LF  access  requires  reading  many  directory  files.  A  copy  directory 
parameter  in  PART  tells  0LF  whether  or  not  the  current  level -three  directory 
must  be  rewritten  onto  disc  before  a  new  one  is  loaded  (equivalent  to  whether 
or  not  the  active  processor  edits  the  directories).  The  file  insertion/ 
deletion  processors,  and  any  multi-step  processors  which  invoke  them,  must 
have  copy  directory  enabled. 

Statistics-gathering  processors  may  need  to  be  invoked  once  after 
the  completion  of  a  batch  access  (e.g.,  to  calculate  standard  deviations  after 
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determining  means).  The  extra  access  parameter  in  PART  tells  0LF  whether  or 
not  the  current  processor  is  allowed  an  extra  access. 

It  should  now  be  clear  that  the  file  I/O  rights  of  a  subprocessor 
must  be  a  subset  of  the  rights  of  its  invoker.  A  subprocessor  cannot  success- 
fully edit  a  file  if  the  initiating  processor  does  not  have  student  file  out- 
put authorization.  A  subprocessor  which  requires  data  from  complete  student 
records  cannot  function  correctly  if  the  processor  invoking  it  requests  a 
partial  read-in  (that  is,  if  the  initial  processor  of  a  multi-step  processor 
has  a  limited  student  file  input  parameter  in  PART).  A  statistics  sub- 
processor  may  not  be  able  to  complete  its  calculations  if  the  processor  using 
it  is  not  executed  once  after  each  batch  access. 

It  is  expected  that  direct  file  access—file  locating  without  use 
of  the  0LF  tree—will  be  used  only  by  CREATE  FILE  (a  sample  processor  discus- 
sed below)  or  processors  invoking  CREATE  FILE.  For  purposes  of  generality, 
the  direct  access  capability  is  included  within  0LF  and  enabled  by  a  direct 
access  parameter  in  PART. 

4.2  Sample  Processors 

The  sample  processors  discussed  below  are  intended  to  demonstrate 
the  ease  with  which  new  capabilities  can  be  added  to  0LF,  and  to  clarify  the 
interface  conventions.  This  section  is  not  an  exhaustive  list  of  useful 
processors. 

4.2.1  CREATE  FILE  (CRFILE) 
File  creation  entails: 

1)  determining  that  the  proposed  file  does  not  yet  exist; 

2)  checking  that  the  directory  of  the  proposed  advisor  has 
room  for  another  student; 
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3)  creating  the  file--with  a  filled  header  and  initialized 
general  information  block,  requirements  check-off  list, 
and  course  history  block; 

4)  adding  the  name  of  the  new  file  to  the  disc  file  of  new 
files  (see  SAFETY  &  SECURITY,  below); 

5)  adding  the  name  of  the  proposed  file  to  the  proper  level- 
three  directory. 

CRFILE  is  the  processor  which  requires  direct  file  access.  The 
mistyping  of  SSNs  is  a  predictable  error.  Standard  0LF  (tree)  access  de- 
termines the  presence  or  absence  of  a  student  file  only  from  a  specific  level- 
three  directory.  The  SSN  of  a  student  known  to  0LF  might  be  the  same  as  the 
number  mistakenly  entered  as  the  SSN  of  the  student  for  whom  the  new  file  is 
to  be  created.  Unless  old  and  new  students  both  have  the  same  advisor,  tree 
access  cannot  discover  that  a  file  named  after  the  proposed  "new"  SSN  already 
exists.  Opening  the  old  file  to  create  the  new  student's  file  destroys  the 
original  record. 

The  SSN  of  a  student  is  sufficient  information  to  enable  0LF  to 
generate  his  file's  proper  name.  If  tree  access  fails  to  find  a  file  with  a 
proposed  new  name,  the  0PEN  subroutine  is  invoked  for  input.  Upon  return,  if 
the  error  flag  is  set,  the  proposed  file  name  is  unknown  to  0LF  (and  PL0RTS), 
and  the  proposed  file  can  be  created.  If  the  file  already  exists,  the  header 
is  read,  determining  to  whom  0LF  believes  that  SSN  belongs.  (Both  forms  of 
access  are  performed  by  0LF,  not  CRFILE.)  The  distinguishability  of  student 
and  advisor  file  names  (see  File  Names,  above)  prevents  attempting  to  read  a 
student  header  from  an  advisor  file,  which  would  cause  a  data  format  error. 

4.2.2  DELETE  FILE  (DLFILE) 
File  deletion  entails: 
1)  determining  that  the  to-be-deleted  file  exists; 
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2)  removing  the  name  of  the  to-be-deleted  file  from  the 
proper  level -three  directory; 

3)  entering  the  name  of  the  file  to  be  deleted  into  the 
deallocated  files  list; 

4)  commenting  when  an  advisor  loses  his  last  advisee. 

4.2.3  GPA  CALCULATOR  (CALC) 

CALC  finds  the  GPA  resulting  from  practically  any  subset  of  courses 
taken  by  any  student.  The  selectable  subsets  are  the  intersections  of  any  of 
the  following  sets: 

1)  all  courses  within  the  major  and  minor  subjects; 

2)  all  courses  within  the  major  subject  only; 

3)  all  courses  within  the  minor  subject  only; 

4)  all  courses  within  a  named  department; 

5)  all  courses  taken  during  and  after  a  specified  semester; 

6)  all  courses  taken  during  or  after  a  given  status  (e.g., 
freshman,  sophomore,  etc.)  is  reached; 

7)  all  courses  within  the  last  given  number  of  hours; 

8)  all  courses  including  and  above  a  specific  level  (100, 
200,  etc.); 

9)  all  courses  not  yet  included  in  the  cumulative  GPA  (grades 
just  recorded). 

CALC  returns,  in  addition  to  a  GPA,  the  number  and  total  hours  of 
the  courses  used  in  the  calculation. 

4.2.4  A  SAMPLE  STATISTICS  PROCESSOR  (USERA) 

Most  user-supplied  processors  are  expected  to  be  statistics-gatherers 
The  sample  processor  described  below  is  intended  to  be  indicative  of  the 
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potentialities  of  0LF;  it  also,  by  invoking  CALC,  illustrates  the  rules 
governing  multi-step  processors  (see  their  respective  PART  entries,  in 
Figure  10) . 

The  XX  department  wants  to  prove  or  disprove  the  belief  of  some  of 
its  advisors  that  the  course  YYY108  should  be  a  prerequisite  for  all  200- 
(and  above)  level  XX  courses.  The  advisors  who  feel  that  YYY108  is  a  useful 
course  have  consistently  recommended  it  to  their  advisees.  This  processor 
will  calculate  and  compare  the  GPAs  in  200-  and  above  level  XX  courses  for 
the  two  sets  of  XX  students:  those  who  took  YYY108  as  suggested,  and  those 
who  did  not. 

The  department  name  (XX),  the  course  name  (YYY108),  and  the  course 
cutoff  level  (200)  are  read  in  by  USERA.  The  input  line  indicating  the  course 
cutoff  level  is  passed  by  USERA,  via  the  input  buffer,  to  CALC.  USERA  conse- 
quently can  be  used  by  any  department  interested  in  any  course;  any  set  of 
courses  which  can  be  selected. by  CALC  can  be  examined  by  USERA. 
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5.   SAFETY  &  SECURITY 

Two  crucial  problems  of  automated  system  design  are  reliability 
(will  the  system  be  available  when  needed)  and  safety  (is  the  system  pro- 
tected against  accidental  and  malicious  tampering).  0LF,  as  a  program  package 
within  PL0RTS,  can  be  no  more  dependable  or  secure  than  PL0RTS  limitations 
allow. 

0LF  is  available  whenever  PL0RTS  is  available.  (A  TSBATCH  job 
can  execute  0LF  programs  when  the  PDP-7  (the  terminal  —  IBM  360  interface)  is 
not  running,  but  the  benefits  of  interactive  processing  are  lost.)  0LF  clearly 
must  be  paralleled  by  an  alternate  system  at  least  at  the  times  of  heaviest 
use--the  registration  and  advanced  enrollment  periods.  Printouts  of  the  0LF 
student  records  can  supply  such  a  supportive  system.  In  most  cases,  advisors 
will  be  able  to  counsel  using  only  the  information  on  such  printouts.  In  the 
event  of  an  equipment  failure,  only  the  printouts  will  be  avail able--but  this 
is  the  situation  under  the  present  record  keeping  system.  A  special  processor 
can  be  added  to  0LF  to  furnish  a  conveniently  formatted  record  from  each  stu- 
dent file. 

The  protection  of  program  files  is  straightforward.  Full  access  to 
any  PL0RTS  file  requires  knowledge  of  the  triplet  (PS#,username,filename). 
Each  user  is  forced  to  use  his  own  copy  of  0LF  (and  its  current  processors)  by 
keeping  the  username  of  a  master  program  file  secret.  As  a  secondary  benefit, 
this  procedure  prevents  user-supplied  processors  of  narrow  applicability  from 
proliferating  in  the  master  program  file.  The  minor  editing  of  0LF  necessary 
before  use  of  a  new  processor  is  made  on  an  0LF  copy,  and,  if  the  processor  is 
to  be  kept,  the  master  copy  can  be  updated  by  authorized  personnel  after  de- 
bugging is  complete.  Extra  copies  should  be  destroyed  after  use.  A  backup 
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tape  copy  of  the  master  program  file  (inaccessible  without  the  tape's  name)  is 
kept  since  a  user  who  learns  the  codeword  might  maliciously  alter  the  program 
file. 

Data  files  must  be  protected  from  undebugged  processors  and  PL0RTS 
(hardware  and  system  software)  failures.  Processor-inflicted  damage  is  possible 
only  when  a  processor  does  not  conform  to  0LF  interfacing  conventions.  A 
processor  with  PART  entries  for  both  partial  student  file  read-in  and  student 
file  output  authorization  may  erase  parts  of  files;  a  processor  with  PART 
student  file  output  authorization  that  returns  an  undeserved  no-error  completion 
code  may  overwrite  correct  information;  a  directory  editing  processor  without 
PART  authorization  for  directory  file  output  can  render  groups  of  student  files 
inaccessible  by  normal  0LF  methods.  Processors  can  be  debugged  with  a  single 
student  file--preferably  of  an  imaginary  student.  A  backup  tape  of  all  data 
files  should  be  prepared  after  each  execution  of  0LF  (as  another  job  step)  in 
case  of  errors  in  the  next  execution. 

0LF  prints  a  message  immediately  before  and  after  invoking  a  proces- 
sor. A  missing  completion  message  indicates  which  file  was  being  processed 
when  a  system  failure  occurred.  A  more  serious  problem  is  the  state  of  the 
directory  files  following  a  system  failure.  DLFILE  maintains  a  file  on  disc 
of  all  student  files  edited  from  level-three  directories  but  not  yet  de- 
allocated. If  DLFILE  was  the  active  processor,  the  last  file  deleted  from  the 
level -three  directory  loaded  at  the  time  of  failure  may  not  have  been  added  to 
the  deallocate  list.  CRFILE  maintains  a  similar  list  of  all  student  files 
added  to  level-three  directories  during  the  current  execution.  If  CRFILE  was 
the  active  processor  at  failure,  the  most  recently  created  file  might  not  have 
been  added  to  the  list.  In  all  cases,  the  output  of  0LF  indicates  which  directory 
and  student  file  were  loaded  when  failure  occurred. 
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If  failure  occurs,  any  insertions  and  deletions  to  the  current  level- 
three  directory  by  CRFILE  and  DLFILE  may  not  be  reflected  in  the  disc  copy  of 
this  directory.  An  error  recovery  program  (see  UTILITIES  PROGRAMS)  revises  the 
directories  to  reflect  the  changes  shown  in  the  create  and  deallocate  lists. 
Any  system  failure  (except  a  head  crash  that  destroys  one  of  the  recovery  files 
at  a  time  when  CRFILE  or  DLFILE  is  executing)  is  recoverable. 

As  programmed,  0LF  data  files  are  not  safe  from  malicious  indi- 
viduals. Files  are  accessible  for  proofreading  and/or  simple  editing  by  ex- 
plicit terminal  command  because  all  file  names  are  constructed  of  characters 
available  on  terminals.  File  security  is  thus  diminished  in  return  for  ease 
of  access.  The  remainder  of  this  section  discusses  possible  changes  to  make 
0LF  more  secure  at  the  expense  of  convenience. 

Files  whose  names  contain  "characters"  not  included  in  the  terminal 
character  set  are  accessible  only  by  program.  A  one-to-one  substitution  of 
non-printable  for  printable  characters—a  simple  table  look-up  procedure- 
suffices  to  adapt  the  present  file  name  generating  subroutine  to  this  naming 
convention.  Malicious  mischief  immediately  requires  a  higher  level  of  effort. 

Added  safety  could  be  obtained  by  keeping  the  substitution  table  in  a 
disc  file  protected  by  a  different  codeword  than  the  master  program  file.  If 
security  is  violated,  a  recovery  procedure  would  be:  change  the  contents  of 
the  substitution  table;  change  the  codeword  guarding  the  substitution  table; 
rename,  according  to  the  new  table  (via  utility  program),  all  data  files. 
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6.   UTILITIES  PROGRAMS 

0LF  must  be  supported  by  several  programs  which  are  not  needed  by 
general  users. 

CRFILE  and  DLFILE  edit  the  level-three  directories;  the  program 
DIRECTORY  EDITOR  (DREDIT)  adds  or  deletes  advisors  and  curricula  in  the  higher- 
level  directories.  DREDIT  is  similar  to  the  other  file  editors,  and  is  kept 
apart  from  0LF  only  because  its  relatively  infrequent  use  does  not  justify  an 
increase  of  0LF  storage  requirements. 

An  error  recovery  program  (RECOVR)  is  used  after  a  PL0RTS  failure 
occurs  following  use  of  CRFILE,  DLFILE,  or  DREDIT.  RECOVR  edits  directories 
to  correspond  to  the  create  and  deallocate  lists  maintained  by  these  programs. 
The  file-copying  program  (C0PY)  and  file-restoring  program  (REC0PY)  safeguard 
all  student  records. 

Envisioned  program-approving  and  progress-assessing  processors  will 
use  various  course  and  prerequisite  data  files.  These  files  will  require  pro- 
grams for  their  creation/deletion/editing,  which  in  turn  might  need  error 
recovery  programs.  Like  DREDIT,  the  latter  will  be  used  too  infrequently  to 
incorporate  in  0LF  proper,  and  will  undoubtedly  be  run  as  independent  programs. 
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7.   CONCLUSION 

An  on-line  filing  (0LF)  system  for  student  records  has  been  de- 
signed and  programmed.  0LF  can  be  instructed  to  access  various  groups  of 
student  records  for  use  by  various  data  processing  subroutines  (processors) 
Since  all  records  are  stored  on-line  and  are  machine  readable,  0LF  provides 
a  statistics-compiling  capability.  It  is  intended  that  0LF  eventually  be 
extended,  by  the  programming  of  new  processors,  into  a  complete  advisory 
and  record-keeping  system. 
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APPENDIX  A 

COMPUTING  SERVICES  OFFICE  DOCUMENTS 
RELEVANT  TO  0LF 

This  appendix  contains  reproductions  of  four  documents  pertinent  to 
the  use  of  PL0RTS  and/or  CALL/36O-0S  F0RTRAN.  Typographical  errors  present 
in  the  original  Computing  Services  Office  documents  have  been  corrected.  Cer- 
tain conventions  observed  in  the  body  of  this  report  differ  from  conventions 
observed  in  the  following  documents. 
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COMPUTING  SERVICES  OFFICE  PLORTS  FORTRAN  H  17-1 

UNIVERSITY  OF  ILLINOIS  at  URBANA-CHAMPAIGN 

FORTRAN  is  a  widely  used  programming  language,  implemented  as  part  of  the 
PLORTS  timesharing  system.  To  use  PLORTS  FORTRAN,  a  person  must  be  authorized 
to  use  the  PLORTS  system,  and  must  have  use  of  a  Teletype-compatible  or  IBM 
2741 -compatible  device.  The  PLORTS  system  is  discussed  in  manual  CSO-1000, 
which  is  available  through  the  consultants,  room  166  DCL,  and  room  83  Com- 
merce West,  or  for  sale  at  the  Illini  Union  Bookstore. 

The  FORTRAN  language  implemented  is  described  in  IBM  manual  H20-0710,  CALL 
360-0S  FORTRAN  LANGUAGE  REFERENCE  MANUAL,  except  that  CALL/OS  commands  (such  as 
FILE)  are  not  implemented  in  PLORTS,  and  the  maximum  record  that  may  be  read  or 
written  using  formatted  I/O  is  80  characters.  A  procedure  to  aid  in  converting 
existing  programs  from  OS/360  FORTRAN  to  PLORTS  FORTRAN,  called  FORTCONV,  is 
described  in  a  separate  reference  guide. 

Once  a  FORTRAN  program  has  been  entered  into  a  PLORTS  file,  the  program 
may  be  executed  interactively  by  typing  FORTRAN.  Execution  of  a  FORTRAN  pro- 
gram may  be  stopped  by  execution  of  a  STOP  statement,  discovery  of  a  run-time 
error,  or  by  typing  KILLL  if  the  program  is  waiting  for  input.  Execution  of  a 
FORTRAN  program  is  halted  every  15  seconds  and  the  user  is  asked  if  he  or  she 
wishes  to  continue.  To  continue,  type  YES  or  Y;  to  stop,  type  NO,  N  or  KILLL, 
e.g., 

1.000  "  THIS  PROGRAM  COMPUTES  MEAN,  VARIANCE  AND  STANDARD 
2.000  "  DEVIATION  FOR  A  SEQUENCE  OF  POSITIVE  NUMBERS  AND 
3.000  "  SAVES  THE  NUMBERS  IN  A  PLORTS  FILE  NAMED  SAVEA. 
4.000  CALL  0PEN(1,'SAVEA\ 'OUTPUT') 
5.000  1  READ(5,*)  A 
6.000  IFCA.LT. 0.0)  GOTO  3 
7.000  WRITE  (1,2)  A 
8.000  2  FORMAT  (E15.6) 
9.000  1=1+1 
10.000  S  =  S  +  A 
11.000  Q  =  Q  +  A*A 
12.000  GO  TO  1 
13.000  3  S  =  S/I 
14.000  Q  =  Q/I  -  S*S 
15.000  A  =  SQRT(Q) 
16.000  WRITE(6,4)  S,Q,A 

17.000  4  FORMAT (14X,' MEAN', 14X,' VARIANCE', 7X,% 
18.000  'STANDARD  DEVIATION '/3F20. 6) 
19.000  STOP 
20.000  END 
FORTRAN 
?1 

?2.0 
?3E0 
?-l 

MEAN  VARIANCE       STANDARD  DEVIATION 

2.000000  0.666666  0.816496 
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COMPUTING  SERVICES  OFFICE  REF-22-1 

UNIVERSITY  OF  ILLINOIS  AT  URBANA-CHAMPAIGN  FORTCONV 

2/8/73 

FORTCONV  is  a  procedure  to  aid  in  the  conversion  of  programs  from  IBM 
FORTRAN  to  PLORTS  FORTRAN. 

The  program  accepts  a  FORTRAN  source  program,  and  outputs  a  PLORTS 
FORTRAN  version.  If  conversion  is  needed  and  is  simple,  (for  example, 
changing  the  C  in  a  comment  to  a  "),  statements  are  converted.  If  conver- 
sion is  more  difficult,  or  would  require  interpretation  of  the  program,  the 
statement  is  flagged  and  deleted  from  the  output. 

Suggested  use  of  the  program: 

//  EXEC  FORTC0NV 

{FORTRAN  program(s)} 

/* 

The  output  from  this  run  may  be  inspected  and  corrections  made.  When 
an  acceptable  PLORTS  FORTRAN  deck  is  produced,  it  may  be  checked  and  filed  at 

the  same  time  by: 

//  EXEC  FORTC0NV 
PS=ps#,NAME=signonname,DEST=filename 

{FORTRAN  program} 
/* 

NOTE:  The  program  will  not  insert  CALL  0PEN  or  CALL  CL0SE  statements. 
The  printed  output  from  the  program  is  relatively  lengthy.  Use  a  lines 
estimate  on  your  ID  card  approximately  equal  to  twice  the  number  of  input 
cards  plus  200. 

A  job  card  (green  card)  and  your  ID  cards  (see  REF-01)  must  be  at  the 
front  of  every  deck. 
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COMPUTING  SERVICES  OFFICE 

UNIVERSITY  OF  ILLINOIS  AT  URBANA-CHAMPAIGN 

URBANA,  ILLINOIS   61801 

360  Notice  No.  1676 
CALL/OS  Load  Modules 

The  PLORTS  CALL/OS  system  has  been  extended  to  allow  for  the  use  of  CALL/ 
OS  load  modules.  The  object  code  generated  from  a  FORTRAN  or  BASIC  compila- 
tion can  be  saved  in  another  file  by  using  the  parameter  'FILE=filename'  on 
the  FORTRAN  or  BASIC  command. 

Examples: 

FORTRAN    FILE=0BJECT1[ .other  parms] 
BASIC     FILE=0BJECT2[, other  parms] 

The  object  code  from  the  compilation  will  be  stored  in  the  file  specified. 

The  original  filename  will  become  a  catalogue  file,  making  normal  PLORTS 

editing  of  the  object  code  impossible.  Note,  this  object  code  is  only  valid 
to  run  on  the  PLORTS  CALL/OS  system. 

In  order  to  run  an  object  program,  issue  an  'EXEC  or  'EXECE'  command 
from  closed  mode.  'EXECE'  like  'OPENE'  allows  access  to  files  under  another 
PS  and  name. 

Examples: 

EXEC      0BJECT1[, other  parms] 

EXECE     9999. SIGNON . OBJECT! [ 9 other  parms] 

Note,  a  BASIC  program  can  not  be  executed  with  the  DEBUG  option  unless  it  was 
compiled  with  DEBUG  at  the  time  the  object  code  was  saved. 

The  examples  above  indicate  that  parameters  can  be  used  to  alter  the  com- 
pilation and  execution  of  CALL/OS  programs.  The  following  parameters  are 
currently  available. 

FILE=filename     (described  above) 

DEBUG  Allows  post-mortem  analysis,  correction  and  restarting  of  BASIC 
programs.  See  OPENMSG  7  for  a  complete  description. 

TIME=dd   where   0<dd<100   dd  controls  the  frequency  with  which 
'CONTINUE?'  prompts  are  issued.  An  executing  program  may 
use  a  minimum  of  dd  seconds  of  CPU  time  between  successive 
prompts.  Default  value  is  5  sec. 

In  addition,  CALL/OS  FORTRAN  file  I/O  has  been  extended  to  allow  data  to  be 
filed  at  the  end  of  an  already  existing  file.  To  use  this  facility  simply  open 
a  file  for  'MOD'  instead  of  'OUTPUT'. 

CALL  OPEN  (8,'FILENAME','M0D') 

This  feature  is  valid  for  both  formatted  and  unformatted  files.  Opening 
a  file  for  'OUTPUT'  will  continue  to  destroy  and  recreate  the  file. 

David  Subject 
DS:jmv  March  5,  1973 
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COMPUTING  SERVICES  OFFICE 

UNIVERSITY  OF  ILLINOIS  AT  URBANA-CHAMPAIGN 

URBANA,  ILLINOIS   61801 

360  Notice  No.  1697 
Modifications  to  CALL/OS 

The  filing  of  CALL/OS  object  code  (Notice  No.  1676)  has  been  modified  to 
eliminate  the  saving  of  certain  unnecessary  data,  thus  reducing  the  amount  of 
code  saved  and  the  number  of  blocks  required  to  save  it.  The  modification 
will  only  effect  programs  using  large  non-initialized  arrays;  that  is,  arrays 
not  initialized  during  compilation  such  as  with  a  FORTRAN  "DATA"  statement. 
Existing  object  modules  may  still  be  executed,  but  must  be  recreated  to  make 
use  of  the  new  feature. 

In  addition,  the  CALL/OS  FORTRAN  "OPEN"  subroutine  has  been  modified  to 
allow  an  optional  4th  parameter  in  which  a  completion  code  can  be  returned. 
This  feature  will  allow  a  program  to  intercept  and  interpret  any  errors  which 
occurred  trying  to  open  a  file  and  continue  executing  if  desired.  If  the  4th 
parameter  is  not  specified  then  any  errors  which  occur  will  terminate  execu- 
tion as  is  now  the  case.  The  4th  parameter  must  be  an  integer*4  variable  or 
member  of  an  integer*4  array. 

Examples: 

CALL  OPEN  (8, 'FILE  NAME ',' INPUT' , I) 
Possible  completion  codes  are: 

0  -  successful  open 

1  -  no  space  available  for  an  'OUTPUT'file 

2  -  'INPUT'  file  does  not  exist 

3  -  'INPUT'  file  is  a  catalog  file 

4  -  'OUTPUT'  file  is  currently  being  used 

5  -  an  illegal  file  name  was  specified 

If  the  return  code  is  0,  the  file  is  open.  In  all  other  cases,  it  is  not, 


Dave  Subject 
April  11,  1973 

DS:jmv 
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APPENDIX  B 
0LF  OPERATIONS  MANUAL 

B.l  Introduction 

This  appendix  is  a  self-contained,  non-technical  manual  for  0LF  users 
(3LF  is  an  on-line  filing  and  data  processing  system  for  student  records.  It 
consists  of  a  data  retrieval  program  and  data  processing  subroutines  (proces- 
sors). Search  commands  and  processor  data  statements  form  the  0LF  instruction 
set. 

0LF  input  records  are  limited  in  length  (by  the  terminal  line  ca- 
pacity) to  seventy-two  characters.  An  input  record  is  divided  into  eight 
fields  to  form  an  0LF  instruction.  A  new  field  begins  every  tenth  character, 
starting  with  the  left-most  character  of  the  input  record.  Fields  one  through 
eight  are  numbered  consecutively  from  left  to  right.  The  contents  of  each 
field  are  left- justified  within  that  field.  Formatted  input  does  not  in- 
convenience an  0LF  user  since  PL0RTS  terminals  can  be  programmed  to  tabulate. 

B.2  Search  Commands 

A  processor  and  a  set  of  student  records  are  selected  by  search  com- 
mands to  initiate  the  processing  of  information.  A  processor  is  specified  by 
a  single  L0CATE  statement;  various  sets  of  student  records  are  selected  by  from 
one  to  three  L0CATE  statements,  as  explained  below.  All  forms  of  search  com- 
mands are  shown  symbolically  in  Figure  11,  where  the  decomposition  of  each 
command  into  fields  is  indicated.  The  symbols  in  field  three  are  replaced  as 
described  below  to  form  syntactically  correct  0LF  instructions. 
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Field— l"  Field— 2  Field— 3 

L0CATE  PROCESSOR  procname 

L0CATE  CRRCLM    curr# 

L0CATE  ADVIS0R   advname 

L0CATE  STUDENT   ssn 

Figure  11.  Search  Commands 

A  processor  is  selected  by  a  single  L0CATE  PROCESSOR  command.  The 
desired  processor's  name,  of  eight  or  fewer  letters  in  length,  is  substituted 
for  the  symbol  "procname"  shown  in  Figure  11.  A  new  set  of  student  records 
must  be  selected  after  each  processor  request. 

The  records  of  the  set  of  all  students  enrolled  in  a  specific  cur- 
riculum are  selected  by  a  L0CATE  CRRCLM  command.  A  six-digit  curriculum  code 
replaces  the  symbol  "curr#"  of  Figure  11. 

The  records  of  all  students  sharing  a  common  advisor  and  enrolled  in 
a  previously  named  curriculum  are  selected  by  a  L0CATE  ADVIS0R  command.  The 
name  of  the  common  advisor,  of  eight  or  fewer  letters  in  length  (truncated  if 
necessary),  replaces  the  symbol  "advname"  shown  in  Figure  11. 

The  record  of  one  student  counseled  by  a  previously  named  advisor  and 
enrolled  in  a  previously  specified  curriculum  can  be  selected  by  a  L0CATE 
STUDENT  command.  The  student's  nine  digit  social  security  number  (SSN)  is 
substituted  for  the  symbol  "ssn"  shown  in  Figure  11. 

The  L0CATE  CRRCLM,  L0CATE  ADVIS0R,  and  L0CATE  STUDENT  commands,  as 
described  above,  are  used  in  conjunction  to  select  single  student  records. 
Individual  access  mode  is  convenient  when  separate  data  is  needed  to  process 
each  file  (e.g.,  when  recording  course  grades).  When  the  data  to  be  processed 
is  present  in  the  student  records  before  processing  begins  (e.g.,  when  compiling 
curriculum-wide  statistics  from  the  completed  coursework  of  students),  a 
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batch-mode  access  of  records—access  of  many  records  by  only  a  few  commands-- 
is  useful . 

Alternate  forms  of  the  non-processor  search  commands  request  three 
levels  of  batch  access.  The  symbols  "curr#",  "advname",  and  "ssn"  of  Figure  11 
take  the  value  "*"  (asterisk)  to  request  access,  respectively,  to:  all  records 
known  to  0LF  (the  records  of  all  students  in  all  curricula),  the  records  of 
all  students  previously  specified  in  a  L0CATE  CRRCLM  statement,  and  the 
records  of  all  students  previously  specified  by  L0CATE  CRRCLM  and  L0CATE  ADVIS0R 
statements.  These  search  strategies  are  called,  respectively,  batch  access 
levels  zero,  one,  and  two.  For  example,  the  commands 


L0CATE 

CRRCLM 

220014 

L0CATE 

ADVIS0R 

SMITH 

L0CATE 

STUDENT 

* 

select  for  processing,  at  batch-access  level  two,  all  advisees  of  Professor 
Smith  in  curriculum  220014.  A  search  command  containing  an  asterisk  completes 
the  definition  of  the  record  set  to  be  processed. 

B.3  Data  Statements 

As  explained  above,  individual  access  mode  is  used  primarily  by 
processors  which  read  data  for  each  student  file  accessed;  batch-access  mode 
is  used  primarily  by  processors  which  use  the  information  already  in  the  student 
records.  Two  data  statement  formats  correspond  to  the  two  access  methods. 

A  data  statement  which  is  to  be  read  by  an  individual -access  proces- 
sor is  labeled  with  the  SSN  of  the  student  whose  record  is  to  be  processed. 
The  label  is  compared  to  the  SSN  of  the  owner  of  the  last-requested  student 
record  to  minimize  erroneous  input.  The  SSN  occupies  the  first  field  of  the 
input  record;  the  remaining  seven  fields  are  filled  to  satisfy  the  information 
requirements  of  the  particular  processor. 
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The  data  read  by  batch-access  processors  relates  to  groups  of 
student  records.  The  word  DATA  in  the  first  field  of  the  data  statement 
identifies  a  batch-access  data  statement.  The  information  required  by  a 
processor  is  located  in  the  remaining  seven  fields  of  the  statement. 

0LF  search  commands  occupy  only  three  of  the  eight  fields  in  each 
statement.  A  processor  (e.g.,  DLFILE,  discussed  below)  can  be  written  to 
extract  information  from  fields  four  through  eight  of  the  last  search  command 
in  a  file  specification.  The  data  fields  of  a  search  command  can  be  used  in 
addition  to  standard  data  statements.  Figure  12  illustrates  the  general  forms 
of  data  statements. 

Field— 1  Field— 2  Field— 3  Field— 4  ...  Field— 8 

333224444  Datum  1  Datum  2  Datum  3  ...  Datum  7 
DATA  Datum  1  Datum  2  Datum  3  Datum  7 
L0CATE    Filetype  Filename  Datum  1       Datum  5 

The  third  statement  is  a  combined  search  command/data 
statement.  If  "Filetype"  is  not  "STUDENT"  then  "File- 
name" must  be  "*"  (i.e.,  data  may  appear  only  on  the 
last  of  a  set  of  search  commands). 

Figure  12.  Data  Statements 

B.4  Errors 

0LF  language  errors  can  be  grouped  into  three  classes:  processor 
errors,  non-translatable  search  commands,  and  invalid  search  commands.  A 
secondary  classification  groups  errors  into  recoverable  and  non-recoverable 
categories:  all  errors  except  non-translatable  search  commands  are  recoverable. 

The  occurrence  of  a  non-translatable  or  an  inconsistent  data  field 
on  a  data  statement  constitutes  a  processor  error.  (The  presence  or  absence 
of  information  in  the  data  fields  of  a  search  command  is  determined  after  the 
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selection  of  an  access  mode;  therefore,  a  processor  error  cannot  be  caused  by 
an  error  in  a  data  field  of  a  search  command  unless  the  command  fields  are 
error-free.)  A  processor  responds  to  an  error  by  printing  an  error  message 
and  either  skipping  the  processing  step  or  performing  only  that  portion  of 
the  processing  step  which  is  independent  of  the  improper  field.  The  particu- 
lar response  depends  on  the  processor  involved. 

A  request  for  an  unknown  student  or  directory  file  constitutes  an 
invalid  search  command.  When  0LF  detects  such  a  command,  an  error  message  is 
printed  and  a  new  search  command  is  requested. 

Another  form  of  invalid  search  command  is  possible  when  CRFILE  (i.e., 
the  file-creating  processor,  discussed  below),  or  a  processor  invoking  it,  is 
active.  0LF  ordinarily  searches  for  a  requested  student  record  only  in  the 
file  of  his  advisor;  when  a  new  file  is  to  be  created,  0LF  must  determine  that 
the  proposed  file  does  not  exist  in  the  file  of  any  advisor.  An  attempt  to 
access  a  file  by  a  general  search  should  be  unsuccessful.  Discovery  of  a  file 
by  general  search  is  an  error  to  which  0LF  responds  by  printing  an  error 
message  and  a  new  search  request. 

A  non-translatable  search  command  error  can  take  two  forms:  a  syn- 
tactically incorrect  statement,  or  a  statement  that  is  out  of  context.  0LF 
syntax  has  been  explained  above. 

0LF  expects  to  receive  commands  according  to  the  hierarchy  of  Figure 
13.  An  out-of-order  statement  is  considered  a  non-translatable  search  command 
error.  A  statement  may  be  out  of  context  because  another  statement  is  missing. 
A  long  series  of  data  statements  could  result  from  omitted  search  commands; 
accordingly,  five  or  more  consecutive  data  statements  are  interpreted  as  a 
missing  search  command— a  form  of  non-translatable  search  command  error. 

The  recoverable/non-recoverable  classification  of  errors  relates  to 
input  mode  and  is  discussed  in  the  next  section. 
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Level        Statement 

1  L0CATE  PR0CESS0R 

2  L0CATE  CRRCLM 

3  L0CATE  ADVIS0R 

4  L0CATE  STUDENT  ' 

3 

5  Data  Statements 


i 
Omitted  when  preceded  by  L0CATE    CRRCLM    * 

2 

Omitted  when  preceded  by  L0CATE    ADVIS0R   * 

3 

Data  statements  are  required  by  processors,  not  by  0LF.  0LF  enforces  a 
limit,  discussed  below,  of  four  consecutive  data  statements. 

Figure  13.  0LF  Statement  Hierarchy 

B.5  Input  Modes 

0LF  was  designed  for  interactive  use.  Interaction,  unfortunately, 
is  \jery   time-consuming  when  large  amounts  of  information  are  being  read  or 
printed.  The  0LF  user  can  choose  card  (off-line),  rather  than  terminal,  input 
mode  in  such  cases. 

0LF  treats  the  two  input  modes  differently  in  three  significant 
areas:  printing,  input  stream  delimiting,  and  response  to  errors.  All  card 
input  is  printed  to  make  possible  the  evaluation  of  0LF  output;  terminal  input 
is  not  printed  since  the  user  can  read  the  input  which  he  himself  has  typed. 

In  terminal  mode,  the  stream  of  data  statements  is  delimited  by  a 
blank  line  (i.e.,  by  typing  carriage-return  as  the  first  character  of  an 
input  record).  A  non-blank  line  which  cannot  be  recognized  as  a  data  statement 
is  an  error.  It  is  unreasonable  to  require  that  blank  cards  be  inserted 
throughout  an  input  deck.  In  card  mode,  the  first  card  in  the  data  stream 
which,  by  error  or  design,  cannot  be  recognized  as  a  data  statement  terminates 
the  stream.  On  the  assumption  that  the  first  statement  following  data  is  a 
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search  command,  the  image  of  this  card  is  retained  for  interpretation  as  a 
command. 

Any  error  detected  by  0LF  in  terminal  mode  can  be  corrected  by  the 
user.  In  card  mode,  0LF  terminates  processing  upon  discovery  of  non- 
recoverable  errors.  A  non-recoverable  error,  as  defined  above,  is  a  non- 
translatable,  out-of-context,  or  missing  search  command.  An  unavailable 
command  might  be  a  L0CATE  PR0CESS0R  statement;  continued  processing  following 
such  an  error  would  jeopardize  the  contents  of  the  student  records. 

It  should  be  clear  that  card  mode  has  both  advantages  and  dis- 
advantages over  terminal  mode.  The  user  can  have  keypunchers  prepare  his 
input  deck,  and  his  job  can  be  run  without  the  need  of  his  periodic  inter- 
vention; an  error,  either  on  his  part  or  on  the  part  of  keypunchers,  may  waste 
a  run.  Certain  jobs  can  best  be  done  off-line  (e.g.,  printing  a  copy  of  each 
student  record  for  back-up  purposes);  jobs  containing  many  search  commands  may 
best  be  run  interactively. 

B.6  Use  of  0LF 

A  user  must  log  into  PL0RTS  to  run  0LF.  The  log-in  procedure  is 
described  in  the  PL0RTS  Guide  (reference  4).  When  card  mode  is  to  be  used, 
log-in  should  be  accomplished  through  the  catalogued  procedure  TSBATCH. 

Processing  is  initiated  by  an  EXEC  command  (see  Appendix  A,  360  Notice 
No.  1676).  0LF  will  type 

INPUT  ON  CARDS— TYPE  YES  OR  NO? 
Terminal  users  should  type  NO;  off-line  users  should  respond  (by  a  card  from 
the  input  deck)  YES. 

Once  the  input  mode  has  been  determined,  0LF  will  type 
TYPE  PR0CESS0R  REQUEST 


46 

to  which  the  user  should  respond  with  a  L0CATE  PR0CESS0R  command.  In  card 
mode,  an  error  at  this  point  causes  termination;  in  terminal  mode,  an  error 
causes  a  processor  request  to  be  printed.  This  is  standard  0LF  response  to 
a  non-recoverable  error. 

Once  the  processor  request  has  been  satisfied,  0LF  types 

TYPE  SEARCH    REQUEST 

to  which  the  user  should  respond  with  an  appropriate  search  command.  Certain 
errors  at  this  point  are  non-recoverable  (see  Errors,  above).  If  the  search 
command  is  acceptable,  but  does  not  constitute  a  complete  search  definition 
(e.g.,  L0CATE    CRRCLM   220014),  another  search  command  is  requested. 

Once  the  search  strategy  is  set,  0LF  attempts  to  access  the  file(s) 
specified.  At  this  point  0LF  determines  whether  or  not  the  curricula  and 
advisors  specified  exist.  Naming  an  unknown  curriculum  or  advisor  in  a  search 
command  is  a  non-recoverable  error. 

Another  error  may  occur  when  CRFILE,  or  a  processor  invoking  it,  is 
active.  The  existence  of  a  proposed  new  file  outside  of  the  directory  of  the 
proposed  advisor  is  noted  by  an  error  message,  and  the  processing  step  in- 
volving that  student  file  is  skipped.  This  is  the  standard  0LF  response  to 
recoverable  errors. 

It  is  a  recoverable  error  in  most  cases  to  specify  a  non-existent 
student  record;  when  CRFILE  or  a  processor  invoking  it,  is  active,  the  request 
of  a  non-existent  file  is  not  an  error. 

Once  a  student  file  has  been  accessed,  or  if  it  is  to  be  created, 
once  it  has  been  found  not  to  exist,  0LF  types 

TYPE  DATA  (IF  ANY) 
? 
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to  which  the  user  should  respond  as  appropriate  for  the  active  processor. 
Some  processors  may  expect  data  from  the  last  L0CATE  statement  in  place  of, 
or  in  addition  to,  any  data  submitted  at  this  time.  0LF  tests  the  data  state- 
ment for  the  proper  format  of  the  current  access  level.  Out-of-format  state- 
ments cause  a  warning  to  be  printed  and,  in  terminal  mode,  the  data  request  to 
be  reprinted.  Data  requests  are  repeated  until  a  data  delimiter  or  a  fifth 
data  statement  is  detected.  Five  consecutive  data  statements  constitute  a 
non-recoverable  error. 

The  user  will  receive  data  requests  before  each  processing  step  when 
in  individual  access  mode.  During  each  batch  access,  data  is  requested  only 
once,  immediately  before  processing  the  first  of  the  set  of  selected  files. 

Prior  to  entering  the  active  processor,  0LF  types  a  message  naming 
the  current  processor  and  the  student  file  to  be  processed.  A  completion 
message  is  printed  upon  return  from  the  processor.  Processor  errors  are 
treated  differently  by  various  processors,  but  are  always  recoverable.  When 
an  error  occurs,  the  unedited  copy  of  the  current  student  record  is  kept. 

Following  an  error-free  processing  step,  certain  processors  require 
0LF  to  edit  its  own  files.  0LF  suppresses  editing  when  an  error  arises  while 
attempting  to  edit. 

When  a  just-completed  processing  step  involves  the  last  of  the  se- 
lected student  records  (as  is  always  the  case  when  in  individual  access  mode), 
0LF  requests  a  new  search  command,  and  the  procedure  repeats.   If  the  last- 
named  curriculum  and/or  advisor  describes  the  next  set  of  student  records,  then 
new  search  instructions  can  begin,  respectively,  with  a  L0CATE  ADVIS0R  or 
L0CATE  STUDENT  command. 


Certain  processors  (e.g.,  USERA,  below)  are  invoked  once  for  each  student 
record  accessed  plus  once  at  the  completion  of  the  batch  access. 
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When  a  completed  processing  step,  or  a  processing  step  which  was 
skipped  because  of  a  recoverable  error,  did  not  use  the  last  of  the  selected 
set  of  student  records,  then  (attempted)  processing  of  the  next  file  begins. 
This  case  occurs  only  when  in  a  batch-access  mode. 

After  completion  of  all  processing  requested  by  a  set  of  commands 
(which  may  consist  of  many  processing  steps  when  in  a  batch-access  mode),  an 
alternate  response  to  0LF's  search  request  is  a  L0CATE  PR0CESSOR  command. 
Following  such  a  response,  a  new  set  of  search  commands  is  required,  starting 
with  L0CATE  CRRCLM. 

The  user,  upon  finishing  all  processing,  can  signal  completion  as  a 
response  to  either  a  processor  search  request  by  typing  D0NE.  0LF  responds 

AFTER  THIS  JOB  ENDS,  TYPE:   RUNN  C0PY. 
PL0RTS  signals  completion  of  a  job  by  printing  ST0P,  and  the  charges  for 
all  computer  time  used.  Entered  after  the  0LF  job  is  completed,  the  RUNN 
C0PY  command  initiates  another  program  which  prepares  a  tape  copy  of  0LF 
files  for  use  in  the  event  of  a  future  PL0RTS  failure.  PL0RTS  will  respond 
by  typing  a  job  receipt.  The  user  may  log-out  after  initiating  C0PY. 

B.7  Present  Processors 

As  of  this  writing,  0LF  includes  five  processors.  A  brief  descrip- 
tion of  each  processor  and  its  data  requirements  is  given  below. 

DUD  is  a  processor  which  performs  no  processing.  It  demonstrates 
safely  to  new  users  the  order  in  which  student  records  are  processed  in  the 
various  access  modes.  Any  input  submitted  to  DUD  is  ignored. 

CRFILE  is  the  processor  which  creates  student  files.  The  L0CATE 
STUDENT  statement  specifying  the  to-be-created  file  must  include  the  following 
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data  items:  the  student's  name  (last  name  first)  in  fields  four  and  five; 
the  proposed  entry  semester  in  field  six;  the  proposed  entry  year  in  field 
seven. 

Another  data  statement  is  used  when  the  student  is  enrolling  in  a 
co-curriculum:  the  characters  C0CRRLM  belong  in  field  two  and  the  co- 
curriculum's  six-digit  code  belongs  in  field  three.  Any  additional  data 
statements  are  ignored. 

CRFILE  signals  (via  its  completion  code)  an  error  in  processing  if 
a  datum  on  the  L0CATE  card  is  non-translatable,  or  if  the  proposed  entry  date 
is  in  the  past.  A  non-translatable  or  unknown  co-curriculum  code  causes 
processing  of  the  co-curriculum  to  be  skipped  but  does  not  prevent  file  cre- 
ation. An  appropriate  message  is  printed  by  CRFILE  in  each  of  the  above  cases. 

If  the  data  on  the  L0CATE  statement  is  acceptable,  the  new  file  is 
created,  containing  the  student's  SSN,  name,  college  code,  curriculum  code, 
advisor's  name,  and  entry  date.  When  submitted  correctly,  a  co-college  code 
and  co-curriculum  code  are  also  stored.  The  remainder  of  the  record  is  ini- 
tialized as  appropriate. 

0LF  discards  the  new  file  if  CRFILE  signals  an  error.  When  proces- 
sing goes  normally,  0LF  attempts  to  add  the  name  of  the  new  file  to  its  master 
files  (directories).  An  error  message  is  printed  and  the  new  file  is  dis- 
carded if  the  directory  of  the  student's  advisor  is  full. 

DLFILE  is  the  processor  which  destroys  existing  student  files.  Fields 
four  and  five  of  the  L0CATE  STUDENT  card  which  specifies  the  to-be-destroyed 
file  must  contain  the  name  of  the  owner  of  that  file,  exactly  as  stored  in  the 
file.  This  comparison  prevents  the  accidental  destruction  of  files.  The  error 
message  printed  when  an  incorrect  name  is  supplied  shows  the  owner's  name,  so 
that  misspelling  can  be  differentiated  from  more  serious  mistakes. 
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If  the  name  field  on  the  L0CATE  statement  matches  the  name  stored 
in  the  student  file  then  normal  completion  is  signalled  to  0LF,  which  removes 
the  name  of  the  file  from  the  appropriate  directory.  If  the  student  file  was 
the  only  file  named  in  the  directory,  a  message  is  printed  identifying  the 
now-empty  directory. 

CALC  is  the  processor  which  calculates  grade-point  averages  (GPAs). 
In  addition  to  a  GPA,  the  number  and  total  hours  of  courses  used  in  the  cal- 
culation are  available. 

CALC  will  find  the  GPA  of  practically  any  subset  of  courses  in  a 
student  record.  When  no  data  statements  are  submitted  (CALC  does  not  look 
for  data  on  a  L0CATE  statement),  the  GPA  is  found  for  courses  not  yet  in  the 
cumulative  GPA--presumably  the  last  semester's  grades.  The  cumulative  GPAs 
of  all  courses,  major  area  of  study,  and  individual  departments  are  also  up- 
dated. 

Combinations  of  data  statements  request  GPA  calculations  on  differ- 
ent subsets  of  the  completed  coursework.  Any  group  of  four  or  fewer  (0LF 
limitation)  of  the  following  statements  may  be  used  to  choose  a  particular  set 
of  courses.  The  GPA  calculation  is  done  with  the  set  of  courses  described  by 
the  intersection  of  the  sets  selected  by  the  individual  statements. 

A  type  of  course  (major  or  minor)  is  selected  by  a  data  statement 
with  TYPE  in  field  two  and  MAJ0R  or  MIN0R  in  field  three.  Both  major  and  minor 
areas  of  study  are  selected  by  using  two  data  statements.  Alternatively,  MAJ0R 
and  MIN0R  can  appear  in  fields  three  and  four  of  a  single  statement  (either 
word  first) . 

Courses  of  one  department  are  selected  by  a  data  statement  with  DEPT 
in  field  two  and  the  five-letter  department  code  in  field  three. 
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Courses  completed  since  a  given  date  (semester)  are  chosen  by  a 
data  statement  with  SEMESTER  in  field  two,  a  semester  name--FALL  (or  AUTUMN), 
SUMMER,  or  SPRING--in  field  three,  and  the  year  in  field  four. 

Courses  completed  since  attaining  a  given  academic  status  are  se- 
lected by  a  data  statement  with  STATUS  in  field  two  and  an  academic  year— 
FRESHMAN,  S0PH0M0RE,  JUNI0R,  or  SENI0R— in  field  three. 

The  last  n  hours  of  coursework  completed  are  chosen  by  a  data  state- 
ment with  H0URS  in  field  two  and  a  non-negative  integer  n  in  field  three. 
The  value  of  n  must  be  written  in  three  digits,  using  non-significant  zeroes 
as  needed. 

Courses  at  and  above  a  given  level  n  (e.g.,  100,  200,  etc.)  are 
selected  by  a  data  statement  with  LEVEL  in  field  two  and  a  positive  integer  n 
in  field  three.  The  value  of  n  must  be  written  in  three  digits,  using  non- 
significant zeroes  as  needed. 

Figure  14  shows  typical  CALC  data  statements. 

Field—!  Field— 2  Field— 3  Field— 4 

333224444  TYPE     MAJ0R     MIN0R 
333224444  LEVEL    200 
333224444  H0URS    030 

The  above  three  statements,  if  submitted  to  CALC, 
would  request  a  GPA  calculation  of  all  advanced 
level  (i.e.,  200-level  and  above)  courses  within 
the  last  thirty  completed  hours  of  study  and  within 
either  the  major  or  the  minor  areas  of  study  for  the 
student  whose  SSN  is  333-22-4444.  Notice  that  the 
number  thirty  (third  statement)  is  written  with 
three  digits. 

Figure  14.  Sample  CALC  Data  Statements 
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USERA  is  a  statistics-compiling  processor  which  helps  determine  the 
value  of  a  course  of  interest  as  a  prerequisite  for  coursework  in  any  chosen 
department.  The  GPAs  of  students  who  have  taken  the  course  are  compared  to 
the  GPAs  of  students  who  have  not  taken  it. 

The  name  of  the  course  and  department  under  consideration  are  sub- 
mitted to  USERA,  respectively,  in  fields  four  and  five  of  a  L0CATE  statement. 
Specific  courses  from  within  the  chosen  department  are  selected  for  the  com- 
parison by  CALC-form  data  statements,  which  are  used  by  CALC.  USERA  generates 
the  data  statement  for  CALC  which  selects  the  chosen  department. 

Figure  15  shows  statements  required  for  a  typical  use  of  USERA. 

Field— 1  Field— 2  Field— 3  Field— 4  Field— 5 
4- .  .4-4' 4-4- 4- 4* 4-4- 4- 

L0CATE  PR0CESS0R  USERA 

L0CATE  CRRCLM  220014 

L0CATE  ADVIS0R  *        XX       YYY108 

DATA  STATUS  SENI0R 

DATA  LEVEL  300 

The  above  statements  command  0LF  to  compare  GPAs  of 
two  groups  of  senior  students  enrolled  in  curriculum 
220014— those  who  have  taken  the  course  YYY108,  and 
those  who  have  not.  Only  300-level  XX  courses  are 
used  in  the  calculations. 

Figure  15.  Sample  Use  of  USERA 
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APPENDIX  C 

NEW  PROCESSORS 

The  capabilities  of  0LF  can  be  increased,  when  desirable,  by  the 

1 
addition  to  0LF  of  new  processors.   This  appendix  is  concerned  with  the  me- 
chanics of  creating  new  processors.  Variable  names  and  statement  numbers  used 
in  the  discussion  below  appear  in  APPENDIX  D:  0LF  PROGRAM  LISTINGS. 

C.l  Changes  in  0LF 

A  few  minor  changes  are  made  in  0LF  to  accommodate  each  new  proces- 
sor. In  combination  with  reference  to  the  program  listings,  the  following 
remarks  should  make  clear  the  nature  and  necessity  of  these  modifications. 

1)  The  number  of  processors  assumed  to  exist  is  given  by 
the  initial  value  of  the  INTEGER*4  variable  R0WS. 

2)  There  should  be  one  row  in  the  INTEGER*4  array  PART 
for  each  processor.  The  PART  entries  of  each  proces- 
sor are  stored  in  one  record  (card  image)  of  the  disc 
file  named  PART,  according  to  a  F0RMAT  of  (5(11, IX)). 

3)  The  name  of  each  processor  is  stored  as  the  value  of 
an  element  of  the  REAL*8  vector  PR0CS. 

4)  Each  processor  may  be  invoked  by  only  a  single  CALL 
statement,  which  in  turn  may  be  reached  only  via  the 
computed  G0  T0  at  statement  569. 

5)  Each  processor  must  accept  the  INTEGER*4  argument 
ERR0R.  ERR0R  is  the  completion  code  of  the  processor: 


System  expansion  is  restricted  only  by  the  TOOK  byte  main  memory  limitation 


54 


a  value  of  zero  implies  error-free  processing;  a  value 
of  one  indicates  a  processing  error. 

C.2  Scratch  Files 

Some  processors  will  use  disc  files  to  save  intermediate  results. 
A  scratch  file  must  not  be  given  the  same  name  as  any  present  or  potential 
0LF  file.  The  file-naming  conventions  have  been  discussed  in  the  text  of 
this  report.  Program  files  and  a  few  data  files  have  names  selected  with- 
out regard  to  any  specific  convention.  These  files  are  named:  0LF,  DREDIT, 
REC0VR,  C0PY,  REC0PY,  BUFFER,  PART,  CURRIC,  DATES,  C0PY1 ,  C0PY2,  SAVE,  CC0PY, 
REST0RE,  DELETE1,  DELETE2,  CRLIST,  and  DLLIST.  Any  other  names  may  be  used 
to  identify  scratch  files. 

C.3  Programming  Aids 

The  task  of  programming  an  0LF  processor  is  simplified  by  the 
modular  structure  and  debug  option  of  0LF.  Several  character-manipulation 
and  file-handling  subprograms  compose  a  large  portion  of  0LF's  code.  With 
the  exception  of  a  subroutine  which  prints  0LF  error  messages,  each  subprogram 
was  written  with  a  far  broader  capability  than  0LF  required.  Each  subprogram 
and  processor  contains  a  set  of  debug  print  statements  which  may  be  enabled 
(disabled)  by  the  initialization  of  the  INTEGER*4  variable  DEBUG  to  one  (zero). 
Utilization  of  0LF  components  thus  simplifies  the  debugging  of  new  processors 
while  minimizing  the  amount  of  new  code  to  be  debugged. 

C.4  Information 

0LF  can  communicate  large  amounts  of  information  to  its  processors. 


Use  of  existent  subprograms,  which  minimizes  storage  requirements,  is  also 
desirable  in  view  of  the  main  memory  limitation. 
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Additional  information  can  come  from  user  input  and  data  files.  This  section 
discusses  the  nature  of  this  information. 

Most  of  the  information  that  0LF  will  share  with  its  processors  is 
found  in  C0MM0N.  This  information  consists  of  a  student  file  (HEADER  through 
DBL0CK)  and  copies  of  directories  and  directory-related  information  (VEC 
through  LL).  Additional  information  may  be  communicated  through  a  processor 
parameter  list.  The  mandatory  completion  code  (ERR0R)  was  discussed  above. 
FINI,  an  INTEGER*4  variable  whose  value  changes  from  zero  to  one  upon  the 
completion  of  a  batch  access,  tells  a  processor  with  extra  access  authoriza- 
tion in  PART  (e.g.,  USERA)  whether  or  not  a  certain  execution  of  the  proces- 
sor is  the  extra  access. 

0LF  accepts  a  maximum  of  four  consecutive  data  statements  (exclusive 
of  data  on  a  search  instruction).  User  input  is  stored  in  the  disc  file 
BUFFER.  A  processor  which  edits  BUFFER  for  its  subprocessor(s)  need  not 
observe  the  four  statement  limit. 

The  remaining  sources  of  information  are  envisioned  system  data 
files.  The  anticipated  expansion  of  0LF  into  a  full  advisory  system  will 
necessitate  the  creation  of  such  data  files  as  course  equivalence  tables  and 
curriculum  requirements  lists.  A  program-approving  processor  would  logically 
read  from  the  former;  a  progress-assessing  processor  would  necessarily  use 
the  latter. 
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APPENDIX  D 
0LF  PROGRAM  LISTINGS 


"  THE    OLF    PROGRAM    PACKAGE 
■t 

H  CLF    MAIN    PROGRAM 
if 

"  VECTOR    CONTAINS    THE    3    DIRECTORIES: 

"  VECTOR(l)     TO    VECTCR(200>    HOLD    CURRIC    (LEVEL-1) 

••  VECTOP(201)     TO    VECTOR(240)     HOLD    A    LEVEL-2    DIRECTORY 

"  VECT0R(241)    TO    VECT0R1260)     HOLD    A    LEVEL-3    OIRECTOPY 

••  MASTER    IS    THE    ARRAY    OF    SEARCH    NODES 

"  MASTER(l)    TO    MASTERJ3)    HOLD    THE    3    SEARCH    NODES 

••  MASTERI4)    HOLDS    AN    ADVISOR    NAMF — RELATED    TO    MASTER(2) 

••  DUPLIC    IS    A    COPY    OF    MASTER 

"  LAST(l)    TO   LASTI3)     HOLD    THE    NAMES    OF    LOADED    DIRECTORIES 

■  PROCS    HOLDS    THE    NAMES    OF    ALL     (ROWS)     AVAILABLE    PROCESSORS 
••  PART     IS    THE    PROCESSOR    ACCESS    RIGHTS    TABLE: 

■  PART   HAS    SIZE    ROWS    X    5 — SO       PROCESSORS    CAN    BE    ADDED 
"  ROW    I    HOLDS    THE    RIGHTS    OF    THE     I-TH    PROCESSOR 

M  COLUMN     1    IS    STUDENT    FILE     INPUT    AUTHORIZATION 

"  COLUMN    2    IS    STUDENT    FILE    OUTPUT    AUTHORIZATION 

"  COLUMN    3    IS    DIRECTORY    FILE    OUTPUT    AUTHORIZATION 

"  CCLUMN    4    IS    DIRECT    ACCESS    AUTHORIZATION 

"  COLUMN    5    IS    EXTRA    PROCESSOR    CALL     AUTHORIZATION 

"  THE    STUDENT    FILE    IS    COMPOSED    OF: 

"  HFADEP,GIB8,GIB4,GIB2tCHEK0V,DCODE,DBL0CK 

"  LINE     IS    THE     INPUT    BUFFER 

M  LENGTH(I)    CONTAINS    THE    NUMBER    OF    ENTRIES    IN    THE     I-TH    DIRECTORY 

"  THE    VALUE    OF    BATCH     INDICATES    THF    ACCESS    MODE: 

"  BATCH=0          ALL    STUDENTS 

"  3ATCH=1          ALL    ST'JCENTS    IN    1    CURRICULUM 

"  BATCH=2          ALL    STUDENTS    OF    I    ACVISOR     IN     I    CURRICULUM 

"  BATCH=3          A    SINGLE    STUDENT 

"  THE    VALUE    OF    STATUS     INDICATES    THE     PROGRESS    OF    A    SEARCH: 

M  STATUS=1    SEARCH  JUST  STARTING 

"  STATUS=?          SEARCH    IN    PRCGPESS 

"  STATUS=3          LAST     ACCESS    OF    SEARCH 

M  STATUS=4         DONE    WITH    OLF 

"  THE    FOLLOWING    VARIABLES    ARE    USED    BY    THE    PROCESSORS: 

■  SLAVE       IS    THF    IMAGE    OF    MASTER 

■  VFC  IS    THE    IMAGE    OF    VECTOR 

"  LL                IS    THE     IMAGE    OF    LENGTH 

"  NODES       IS    THE    IMAGE    OF    LAST 
ii 

REAL*8    CURRIC/'CURR I C /, VECTOR ( 260 ), LAST( 4) M* 'DUMMY' / ,% 
OUT, GIB  8(5) ,FLAG/'  ????????•/ ,LOC ATE/ • LOCATE •/, PROC, % 
DONE /•DONE' / , ANS ( 4  1/ »CRRC LM«  f • AD VI SOR ' ♦ •STUDENT*  , • PROCESSOR • /ft 
DUMMY/*  DUMMY'/,  PROCS  (5  )  /  •  CP  F  ILE  •  ,  «  DLF  ILE  ■  ,  'CALCS 
•DUD',iUSERA,/,LIST(2)/»CRLIST« , • DLL  I  ST  •  / , DCODE (12 )  ,  % 
MASTER (4), SLAVE (4  1  ,VEC( 260  ), PRCS SR/ • PROCESSOR' / ,% 
DUPLIC(4)  ,N0DES(4)  , EOUI V ,DAT A/ • D    A    T    A'/,? 
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EQU(8),PR0B(8)/3**  *,*N  A  M  E  *,*D    A  B  *,*0  V  E    * ,S 

2**  */,NAME2 
INTEGER*2  HEADER  (32)  ,STAR/  •*•/,*$/•$$•/  ,GI  B2(  20  ),  55 

CHEK0V(12),DBLDCK( 56, 12 ) , LI NE( 72 ) ,BL/«  •/ 
INTEGER  ERR, OK, ST ATUS, BATCH/0/, AUX ,LLEN (3 ) , SKIP/0/,? 

L 1(3) /I, 201, 241 /,L 3(31/0,20,0/, TYPE (4 >/2  ,5,  1  ,5/ ,3 

PGM,ERROR,CARD/0/,CEBUG/0/,YES/*YES*/,N0/*NO*/,PR,? 

COPY  (3  ) /3*0/,  LENGTH  3  1/3*1/,  PART  (5,  5  ),f 

FINI ,ROWS/5/,BEGIN/0/,DUP,LL(3) , BB/O/ ,PTR, VI ( 2 ) / • INTO* , • FROM • / 
REAL    GIB4(16),V<2)/*     *,*DEST*/ 
COMMON    HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 

VEC, SLAVE, NODES, LL 
EQUIVALENCE    (HEADER! 1),EQU( 1 ) ) , ( L INE ( 1 ) , EQUI V) 
C0MPLEX*16    END(2) /•NORMALLY* ,* IN    ERROR1/,? 

POSSIBi 2)/* PROCESSOR* ,* SEARCH*/ 

N 

"  INITIALIZATION 

ii 

»  LOAD    PROCESSOR    ACCESS    RIGHTS    TABLE     (PART) 

ii 

CALL    OPEN( 1,*PART* ,*  INPUT*  ) 

RE AC (1,2) ( (PART( I ,J)  ,  J=l , 5 ) , 1= 1, ROWS ) 

2  F0RMAT(5(I1,1X)) 
CALL    CLOSE(l) 

IF     (DEBUG.EQ. 1) WRITE (6,2000) ( (PART ( I , J ) , J= 1 , 5 ) , 1=1, ROWS) 

?000       FORMAT!*    *P AR T: • / (  IX  ,  51 2 ) ) 
•i 

"  LOAD    THE    LEVEL-l    DIRECTORY    CURRIC 

•i 

CALL    LCAD (1, CURRIC, 0, LAST, VEC TOR, LENGTH, CURRIC, 0) 
•i 

M  DETERMINF    INPUT    MODE — CARDS    OR    TERMINAL 

w 

3  WRITE(6,4) 

4  FCPMATC  INPUT  ON  CARDS — TYPE  YES  OP  NO*) 
PEAD(5,5)  UK 

5  F0PMATIA4) 

IF  ( IJK.EQ.NO)  GO  TO  99 

IF  (  IJK.NE.YES)  GO  TO  3 

CARD=l 
99     PR=1 
it 

•*       REQUEST  PROCESSOR  (OR  SEARCH)  COMMAND 
•i 

6  WRITE(6,7)  POSSIB(PR) 

7  FOPMATC  TYPE  *,A9,*  REQUEST*/) 
IF  (SKIP.NE.O)  GO  TO  10 
READ(5,8)  LINE 

8  FORMAT172A1) 

IF    (CARD.NE.l )    GO    TO    12 

10  WRITE(6,11)    LINE 

11  F0PMAT(1X,72A1) 

12  SKIP=0 
STATUS=1 

20  ERR=0 
DUP=0 
0K  =  0 
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tt 
•• 

N 

tl 
II 
•I 

30 


•• 
•i 
ii 

35 

•• 
•i 

M 

40 

it 
•i 
•i 
45 


it 
ii 
•• 

50 

•« 
tt 
•• 

52 


ii 

53 

55 

ti 
it 


FINI=0 
INCR=0 

TEST    CURRFNT    STATUS 

IF     (STATUS-2)     30,200,1000 

DETERMINE    THE    NEW    SEARCH    STRATEGY 

ITYPE=5 
LEN  =  8 
ISTART=1 

TRANSLATE     1ST    FIELD 

CALL    CCNVRT(0UT,ITYPF.,LINE,LEN,AUX,1,ERR,6555) 
IF     (OUT. E0. LOCATE)    GO    TO    45 
IF     (OUT. NE. DONE)    GO    TO    40 

FINISHED    WITH    THIS    PROCESSOR 

STATUS=4 
GO    TO    150 

INPUT    CANNOT    BF    TRANSLATED 

ERR  =  5 

GO    TO    555 

TRANSLATE    2ND    FIELD 

ISTART=11 

CALL  CONVRT(OUT,ITYPE,LINE,LFN,AUX, 11,EPP,6555) 

DO  50  1=1,4 

DETERMINE  BATCH  ACCESS  LEVEL  FOP  THF  NEW  SEARCH 

IF  (OUT.EQ.ANSU  J  )  GO  TO  52 

CONTINUE 

GO  TO  40 

IS  THIS  A  REQUEST  F CR  A  NEW  PROCFSSOR? 

IF  (PR.EO. 1)  GO  TO  56 

IF  (I.E0.4)  GO  TO  58 

IF  (I.LE.BATCH+1)  GO  TO  55 

MUST  SPECIFY  A  NODE  KEARFR  TO  THF  ROOT 

EPP=6 

GO  TO  5  55 

BATCH=I-1 

IF  (LINE(21).NE.STAR )  GO  TO  60 

THE  LAST  NODE  SPECIFIED  IS  THE  ROOT  OF  THE 
SEARCH  SUPTREE 
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56  MASTER(I)=FLAG 
LLEN( I )=0 

IFU.EQ.3)    GO    TO    57 
1  =  1*1 

GO    TO    56 

57  STATUS=1 

GO    TO    150 
it 

"  MUST    TRANSLATE    THIS    NODE    NAME 

n 

58  IF    (LINE(21).EQ.STAR)    GC   TO    132 
60  ISTART=21 

ITYPE=TYPE(I) 
IF    (I.NE.3)    GO    TO    120 
IF    (BATCH. EQ. 2)    LEN=9 
it 

"  TRANSLATE    3RD    FIELD 

ti 

120         CALL    CONVRT(OUT,ITYPE, LINE, LEN , AUX , I  START , ERR, 6555 ) 

MASTER (I)=OUT 
ii 

»  PROCESS    THE    NEW    LINE 

•i 

IF     (I.NE.4)    GO    TO    130 
DO    122    PGM=1,R0WS 

IF     (OUT.EQ.PROCS(PGM)I    GO    TO    125 
122         CONTINUE 
ERR  =  5 

125  PROC=PROCS(PGMJ 

IF  (DEBUG. EQ. I)  WRITE(6,126)  PROC 

126  FORMAT! •  *THE  ACTIVE  PROCESSOR  IS  •  ,A8) 

BB=0 
ti 

■  GET    THE    NEXT    SEARCH    SPECIFICATION 

PR=2 
BATCH=0 
GO    TO    6 
130         IF    (PR.NE.l)    GO    TO    133 

132  ERR=11 

GO    TO    555 

133  IF    (I.NE.3)    GO    TO    135 
BATCH=3 

STATUS=1 

GO    TO    150 

135  IF    (I.EQ.l)    CALL    R ENAMEI $$, MASTER ( 1 ) ) 

IF     (I.E0.2)    MASTERU)  =  NASTEP(2) 

BATCH=BATCH+1 
n 

"       READ  NEXT  LINE  OF  TFE  SEARCH  SPECIFICATION 
ti 

GO  TO  6 

M 

M       ACCESS  A  STUDENT  FILE 
•• 

150    IF  (STATUS. NE . 4)  GO  TO  200 
n 
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"  PREPARING    TO    TERMINATE    JOB 

it 

152         WPITE{6,155) 

155  FORMATC     GOING    INTO    FINAL    WRAPUP1) 

IF     (COPY(3).EQ.l)     CALL    LOAO( 3, DUMMY, COPY( 3 ), L AST, VECTOR ,S 
LENGTH, DUMMY, 0) 

WRITE(6,165) 
165         FORMAT!'     AFTER    THIS     JOB    ENDS,    TYPE:','     RUNN    COPY') 

STOP 
•• 

«  ACCESSING    STUDENT    FILES 

ii 

200  IF     (CEBUG.EO.l)    WR  I  TE( 6, 2030}     STATUS, BATCH , (MASTER ( MM ) ,MM=1 ,3 ) 

2030      FORMATC    *SEARCH    STRATEGY    DETERMINED:*? 

•     STATUS=», I1,5X,»EATCH=* ,Il,/»     MASTERS , 3A12 ) 

ILK  =  0 

KK=BATCH+1 

1  =  1 

IF    (STATUS. GT.l)    GO    TO    215 

STATUS=2 

BB=0 

KM=1 

210  IF     (MASTER(I).NE.FLAG)    GO    TO    220 

ii 

"  FIND    THE    NAME    OF    THE    NEXT    LEVEL-I     DIRECTORY 

N 

215         I=KM 

MASTER  (I)  =VECT0R(L1(  I)+LLEN(I  )+L3(I)) 

LLEN(  I  )  =  LLEN(I )  ♦  1 

217  DUP=1 

GO    TO    222 
n 

M  IF    MASTER(I)     IS    THE    CURRENT    LEVEL-I    DIRECTORY, 

"  IT    MUST    EXIST 

•t 

220  IF     (MASTER! I) .EQ.LASTl 1+1) )    GO    TO    217 

•« 

"  SEARCH    FOP    MASTER(I)     IN    DIRECTORY(I) 

M 

CALL    BISECT (VECTOR, LENGTH, MASTER (I ),DUP,PTR, I, LAST) 
LLEN( I  )=PTR-L1( I)*l 
IF     (DUP.EQ.O)    GO    TC    222 

IF    (I.EQ.2)    MASTER(2)=VECT0P(PTR+L3(2) ) 
222  DUPLICd  )  =  MASTER(I) 

IF     (I.EQ.2)     DUPLIC(4)=MASTER(4) 
IF    (DUP.NE.O)    GO    TO    225 
IF     (I.E0.3)    GO    TO    260 


THE    DIRECTORY    JUST    REQUESTED     IS    UNKNOWN 


GO    TO    300 
225  NAMF2=VECT0R(L1(I )+LLEN( I)-l) 

IF     ( I.EQ.3)    GO    TO    26C 

"  LOAD    FILE    NAMED    MASTER(I)     INTO    LEVEL-(I+1)    DIRECTORY 

N 

KARD=CARD 
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CALL    L0AD(l4-l,MASTERU)  t  COP  Yd  +  1 1 ,  LAST  ,  VECTOR  ,  LENGTH,  % 

NAME2,KARDI 

1*1*1 

KM=KM*1 

IF    <LENGTH(  I)  .NE.O)    GO    TO    210 

IF    (BATCH. NE.3)    GO   TC    240 

DUP  =  0 

STATUS=3 

DUPLIC(3)=MASTER(3) 

PTR=L1(3) 

GO    TO   290 

240 

LLENU)=LLEN(I)+1 

ILK=1 

1  =  1-1 

GO    TO    261 

260 

0UT=MASTER(3) 

it 

IF    (BATCH. EO. 3),   GO    TC    263 

n 

it 

IS    THE    BATCH    ACCESS    COMPLETED    WITH    THIS   LAST    FILE? 

261 

J=3 

262 

IF    (LLEN(J).LT. LENGTH! J))    GO    TO    265 

J=J-1 

IF    (J.GE.KK)    GO    TO    262 

263 

STATUS=3 

GO    TO    290 

265 

KM=J 

IF  (J. NE.3 )  GO  TO  267 

MASTER(3)=FLAG 

GO  TO  290 
267    KI=LLEN(J) 

DO  270  L=J,3 

LLEN(L)=0 
270    MASTER(L)=FLAG 

LLEN(J)=KI 
290    IF  (ILK.EQ.O)  GO  TO  295 

H 

M       AN  EMPTY  DIRECTORY  V.AS  SPECIFIED 

N 

ERR=12 
GO  TO  555 
ii 

"       IF  THE  FILE  WAS  FOUND— GO  PROCESS  IT 
ii 

295    IF  (DUP.EO.l)  GO  TO  350 

IF  (I. NE.3)  GO  TO  300 
it 

"       DOES  THE  CURRENT  PROCESSOR  HAVE  DIRECT  ACCESS  OK? 

M 

IF  (PART(PGM,4).EQ.l  )  GC  TO  305 
ii 

H  THE    LEVEL-J    FILE    JUST    REQUESTED    IS    MISSING 

ii 

300    ERR=6+I 
FINI=1 
GO  TO  555 
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"  TRY    TO    ACCESS    THE    STUDENT    FILE    DIRECTLY 

N 

305         CALL    OPEN(1,OUT,  'INPLT'  ,K| 

IF     (K.EQ.O)    GO    TO    320 
n 

"  FILE    DOES    NOT    EXIST 

•i 

DO  310  1*1,8 
310         EQUd  )=PROB(I  ) 

DO  315  1=1,9 
315         HEADER!  I)  =  LINEU  +  20) 

GO    TO    500 

H 

"  THE    FILE    EXISTS — FIND    OUT    ITS    OWNER 

N 

320         ERR=3 

READ(1,355)    HEADER, GIB8 

CALL    CLOSEd) 

GO    TO    555 
350         IF    (DEBUG. EQ.l)    WRITE(6,352)    OUT 
352         FORMAT!*    *NOW    READING    STUDENT    FILE     ',A8) 

N 

"       READ  IN  THE  APPROPRIATE  APCUNT  OF  THE  STUDENT  FILE 

M 

CALL  OPEN(l  , OUT, 'INPUT* ) 

READl 1,355)    HEADER , G IB8,GI B4,G 1 82 ,CHEKOV 
3  55  F0RMAT(32A1,5A8/16A4/20A2, 12A1) 

IF     (PART(PGM, I) .EQ.l)    REAC(1,360)     DCODE,DBLOCK 
360  F0RMAT(6A8/6A8/(28A2)) 

CALL    CLOSEd) 


n 
it 


MAKE    SURE    THAT    THIS    STUDENT    IS    IN    THE    RIGHT    CURRICULUM 

IF    (DUPLICll).EQ.GIB8(2) )    GO    TO    500 

WRONG    CURRICULUM — ACVISOR    COUNSELS    >1    CURRICULUM 

DUP=0 
ERR  =  4 
GO  TO  555 

M 

"       LOCK  FOR  INPUT  IF  IN  INDIVIDUAL  ACCESS  MODE 

"       (BATCH=3)  OR  IF  ON  1ST  ACCESS  OF  A  BATCH  ACCESS 
it 

500    IF  (BATCH. EQ. 3)  GO  TC  501 
IF  (BB.EQ.O)  GO  TO  501 
GO  TO  555 


N 
•I 

501    BB=1 


BUFFER  INPUT  TO  THE  PROCESSOR 


CALL  OPEN( 12,  'BUFFER ',  'OUTPUT*  I 
WRITE(12,8)  LINE 

H 

"  REQUEST    DATA    FOR    PROCESSOR     (IF    ANY) 

ii 

NUM=1 


63 


502  ITRY=1 

503  WRITE(6,504) 

504  FORMATC  TYPE  OATA  (IF  ANY)'/) 
READ(5,8)  LINE 

IF  (BATCH. EQ. 3)  GO  TO  508 

IF  (EQUIV.EQ.DATA)  GC  TO  530 

GO  TO  513 
508    00  510  1  =  1  ,9 

IF  (HEADERU)  .NE.LINEI  I))  GO  TO  513 
510    CONTINUE 

GO  TO  530 

513  IF  (CARD. NE. II  GO  TO  514 
SKIP=1 

GO  TO  540 
•i 

"       ACCEPT  A  CARRIAGE  RESTORE  AS  END  OF  DATA 

"       WHEN  IN  TERMINAL  INPUT  MODE 
it 

514  DO  515  1=1,72 

IF  (LINE(I).NE.BL)  GC  TO  520 

515  CONTINUE 

GO    TO    540 
it 

"  CANNOT    TRANSLATE    LAST    LINE 

•i 

n 

"       GET  FOUR  CHANCES  TO  GET  IT  RIGHT  WHEN 
"       IN  TERMINAL  INPUT  MODE 

M 

520    IF  (ITRY.GT.4)  GO  TO  525 

IF  (BATCH. EQ. 3)  WR  ITE ( 6, 522) ( L INF ( M ) , M= 1,9 ) 

522  FORMAT( 1X,9A1,'  DOES  NOT  MATCH  THE  SSN  OF  THE  ',% 

•REQUESTED  FILE') 
IF  (BATCH. LT. 3)  WPITE(6,523) 

523  FORMAT!'  TYPE  "DATA     "  IN  COLUMNS  ',« 

•1  TO  8  FOR  BATCH  MODE  DATA  INPUT') 

ITRY=ITRY+i 

GO  TO  503 

525    ERR=5 

GO  TO  540 
n 

"       TRANSFER  THIS  LINE  TO  THE  BUFFER 

N 

530    WRITE(12,8)  LINE 

IF  (CAPD.EQ.l)  WRITE(6,11)  LINE 

NUM=NUM+1 

IF  (NUM.LE.4)  GO  TO  503 
ii 

"       TOO  MUCH  INPUT 
w 

ERR=2 

540    CALL  CL0SE(12) 
n 

"       PRINT  STATUS  BEFORE  CALLING  PROCESSOR 

M 

555    CALL  OUTPUT(ERR, PROC, BATCH, DUPLIC, LAST, I, GIB8,% 
LINE, HEADER,  I ST ART  ,LEN, NAME2 , OK) 
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■  IF    THERE»S    BEEN    AN     ERROR    ABOVE,    SKIP    PROCESSONG    STEP 

it 

IF    (1-OK)    556,560,637 
•• 

'•  SERIOUS    ERRORS—CAUSE    TERMINATION    IN    CARD    MODE 

M 

556  IF     (CAPD.EQ.O)    GO    TO    99 
WRITE(6,557) 

557  FORMAT! •  SINCE  INPUT  IS  ON  CARDS,  PROGRAM  MUST  STOP') 
GO  TO  152 

•i 

"  PREPARE    FOR    BRANCH    TO    CURRENT    PROCESSOR 

H 

560         ERROR=0 

DO  562  1=1,4 
562    SLAVE(I)  =  DUPL  ICC  I) 

DO  568  1=1,3 

K=LENGTH( I  ) 

LLU)  =  K 

IF  (I.E0.2)  K=K+L3(I) 

M=L1(I  ) 

DO  567  J=M,K 

567  VEC(J)=VECTORCJ) 

568  NODES( II=LAST(I ) 

N 

"       BRANCH  TO  PROCESSOR 

N 

569  GO  TO  (570, 575, 580, 585,590), PGM 

570  CALL    CRFILEIERROR,INCR,DUP) 
GO    TO    600 

575         CALL    DLFILECERROR, INCR ) 

GO    TO    600 
580  CALL    CALC(GPA, HOURS, ERPCP,NUM, 1,0) 

GO    TO    600 
585         CALL    DUD 

GO    TO    600 
590         CALL    USERA(ERROR,FINI) 
•i 

"  IF    THE    PROCESSOR    SIGNALLEC    AN    ERROR,     DISALLOW    OUTPUT 

H 

600  IF     (ERROR. NE.O)    GO    TC    630 

H 

■       IS  THERE  DIRECTORY  EDITING  AUTHORITY? 

"        (EDITING  NOT  ALLOWED  AFTER  STATISTICS  ACCESS) 
ii 

IF  (FINI.EO.l)  GO  TO  630 
IF  (PART(PGM,3) .EO.O)  GO  TO  610 
n 

"       DOES  IT  WANT  TO  EDIT  THE  DIRECTORY? 

M 

IF  (  INCP.EQ.O)  GO  TO  610 

NAME2=MASTER(4) 

CALL    REVISE(VECTOR,LENGTH,OUT,OUT,PTR,3,INCR,LAST,ERROR,NAME2) 
n 

"  IF    THE    EDITING    SUBPROGRAM    REPORTS    AN    ERROR,    DISALLOW    EDITING 

•i 
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IF    <EPPOR.NE.O)    GO    TO    630 
n 

"  THE    DIRECTORY    WILL    BE    REWRITTEN   ONLY    IF 

«  THIS    FLAG    IS    SET 

N 

C0PY(3)=1 
K=INCR 

IF  (K.EQ.-l)  K=2 
CALL  0PEN(1,LIST(K), 'MOD') 
WRITE (1,605)  V(K) ,OUT ,V l( K ) ,DUPL IC ( 2 ) 
605    F0RMAT(A4,1X,A8,10X, A4,1X,A8) 
CALL  CLOSE(l) 

»       IS  OUTPUT  OF  THE  STUDENT  FILE  AUTHORIZED? 
ii 

610    IF  (PART(PGM,2) .EQ.O)  GO  TO  630 

CALL  OPEN( It OUT, 'OUTPUT') 

WRITE  (1,615)  HEADER,C-IB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK 
615    F0RMAT(32Al,5A8/16A4/20A2f  12A1 /6A8/6A8/ (28A2  )  ) 

CALL  CLOSE(l) 

M 

"  WRITE    COMPLETION    MESSAGE 

ii 

630    ERR0R=ERR0R+1 

WRITE(6,635)  PROC, END (ERROR ) 

635    F0RMAT(1X,A8, •  ENDED  f,A16) 
ii 

"  AFTER    STATISTICS    WRAPUP    ASK    FOR    NEW    PROCESSOR 

•• 

637         IF    (FINI. EQ.l)    GO    TO    6 
n 

M       CHECK  SEARCH  STATUS 


GO  TO  20 
PREPARE  FOR  STATISTICS  WRAPUP — IF  ANY 


1000   IF  (PART(PGM,5) .EQ.O)  GO  TO  6 
EPR  =  1 
FINI=1 
GO  TO  555 

END 


OLF    PROCESSORS 

PROCESSOR    CRFILE    CREATES    EACH    NEW    STUDENT    FILE 

SUBROUTINE    CR FILE ( ERROR, I  NCR, DUP) 

REAL*8    DCODE( 12),GIB8(5) ,S LAVE ( 4 ), OUT, BLANK/'     '/,VEC( 260) , NODES( 4 ) 

INTEGER*2    LLINE(72) , CBLOCK ( 56 , 12) , GIB2 ( 20)  ,CHEKOV( 12) ,HEADFR( 32  >,? 

M(20),BL/'     '/,ZEPO/'0'/ 
REAL    GIB4(16) 

INTEGER    ERROR, DEBUG/ 0/ , DUP, ENTRY, LL (3) ,$$*2/'$$'/ 
COMMON    HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,% 
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VEC,  SLAVE, NODES, LL 

EQUIVALENCE  (GI B8 (  1)  ,M( 11  I 

IF  (DEBUG. EQ.l)  WRITE(6,5) 
5      FORMATC  *ENTERING  CRFILEM 

CALL  OPEN( 12, 'BUFFER', 'INPUT* ) 

READ(12,8)  LLINE 

8      FORMATI72A1) 

IF  tDUP.EO.O)  GO  TO  20 
it 

"  THE    PROPOSED    FILF    ALREADY    EXISTS 

it 

WRITE<6,10) 

10     FORMATC  THE  PROPOSED  FILE  ALREADY  EXISTS') 

GO  TO  990 
ii 

■       DOES  THE  NAME  FIELD  CONTAIN  ANY  TYPOS? 
•i 

20     CALL  CCNVRT(OUT, 3, LLINE, 20, JUNK, 31, ERROR, &990) 
ii 

••       IS  THE  PROPOSED  ENTRY  DATE  OK? 

CALL  TIMES(ENTRY,LLINE,51,61,K,ERR0R,£990) 
IF  (K.GE.O)  GO  TO  60 
WRITE(6,40)(LLINE( I ) ,1=51,65) 
40     F0RMATI1X, 15A1,«  IS  PAST — CAN''T  BE  AN  ENTRY  DATE') 
GO  TO  990 

M 

"  INITIALIZE    THE    NEW    FILE 

N 

60  DO    70    1=1,30 

70     HEADER( I)=LLINF( 1+20) 

HEADER!  10)  =  BL 

HEADER<31)=BL 

HEADER<32)=BL 

DO    90    1=1,12 
90  CHEKOVU  )  =  ZERO 

DO    100     1=1,16 
100         GIB4(I)=0.0 

DO    110    1=1,20 
110         GIB2(I)=0 

GIB2(2)=ENTRY 

GIB81 1)=BLANK 

GIB8(2)=SLAVE(i) 

GIB8(3)=SLAVE<4) 

GIB8U)  =  BLANK 

GIB8(5)=BLANK 
ii 

"  INSERT    COLLEGE    CODE    FRCM    2ND    BYTE    OF    CURRICULUM    CODE 

it 

M(  1  )  =  M(6) 

N 

INCR=1  TELLS  OLF  TO  ADD  THE  NEW  FILE  TO  THE  ADVISOR  LIST  AND 
TO  THE  LIST  OF  NEW  FILES 

INCR=1 
K=0 


•i 
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•       IF  THERE  IS  NO  MORE  CATA — RETURN 
n 

READ(12,8,END=1000)  LLINE 
K=l 
if 

"  PROCESS    CO-CURRICULUM    FIELD 

N 

CALL  CONVRT(OUT,2,LLINE,8, JUNK, 21 , ERROR ,£1 15) 

GO  TO  300 

it 

"       LET  MISTAKE  IN  CO-CURRICULUM  GO  BY  WITH  A  WARNING 
n 

115    ERROR=0 

WRITE(6,120) 
120         FORMAT!'    CREATING    THE    FILE    WITHOUT    CO-CURRICULUM*) 

GO    TO    1000 
it 

••  MAKE    SURE    THAT    THE    PROPOSED    CO-CURRICULUM    EXISTS 

•• 

300         CALL    RENAME($$,OUT) 

CALL    BISECTIVEC.LL , OUT, DUP,PTR,1, NODES) 

IF    (DUP.EQ.l)    GO    TO    350 

WRITE16,310)    OUT 
310         FCRMAT(«    CURRICULUM     ',A8,'     IS    UNKNOWN*) 

GO    TO    115 
350         GIB8(5)=OUT 
ii 

"  GET    CO-COLLEGE   CODE    FRCM    CO-CURRICULUM    CODE 

ii 

M( 13)*M(18) 

GO  TO  1000 
990    ERR0R=1 

1000       IF     (DEBUCEQ.l)    WR  I  TE  (6  ,  1005  )    ERROR 
1005       FORMAT*'    ^LEAVING    CRFILE — EPR0R=',I1) 

RETURN 

END 
•• 

M 
•I 

n 

"  PROCESSOR    DLFILE    DELETES    EACH    OBSOLETE    STUDENT    FILE 

M 

SUBROUTINE  DL F ILE ( ERROR , I  NCR ) 

REAL*8  VEC(260),DC0DE( 12) ,G I B8( 5 ) , SLAVE (4) , OUT, NODES ( 4) ,GIB4*4(  16) 

INTEGER*2  LLINEI72) ,  CBL0CM56, 12) , GI B2 ( 20 ) , CHEKOVl 12 ), HEADER ( 32 ) 

INTEGER  ERROR, DEBUG/0/, LL(3) 

COMMON    HEADER,GIB8,GIB4,GIB2,CHEK3V,DC0DE,DBL0CK,S 

VEC, SLAVE, NODES, LL 

IF    (DEBUG. EO.i)    WRITE<6,5) 

5  FORMATC    +  ENTERING    DLFILE') 

•• 

"  COMPARE    HEADER    TO    THE    NAME    FIELD    IN    THE    DELETE    REQUEST 

ii 

20  CALL    OPEN! 12, 'BUFFER ', 'INPUT' ) 

READ(12,22)    LLINE 
22  F0RMAT172A1) 

CALL    CL0SEU2) 
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DO  25  1=11,30 

IF  <LLINEU«-20).NE.HEADER(I  ))  GO  TO  30 
25     CONTINUE 
GO  TO  40 

M 

"  NAMES    DON'T    MATCH 

n 

3  0  WRITE (6,35) (HEADERC  I  ),  1  =  11,30) 

35  FORMATP    NAMES    DIFFERENT — FILE    FOR     »,20A1) 

GO    TO    990 
w 

"  ADD    COMPLETION    DATE    TO    THE    FILE 

rt 

40  CALL    OPEN(  1, 'DATES'  ,  'INPUT*  ) 

READ(1,45)    GIB2(7) 
45  F0RMAT(I5) 

CALL    CLOSE(l) 

N 

"  INCP=-1    TELLS    OLF    TO    DELETE   THE    FILE    FROM    THE    ADVISOR 

"  LIST    AND    TO    ADD    IT    TO   THE    OBSOLETE    FILE   LIST 

ii 

INCR=-l 

GO    TO    1000 
990         FRR0R=1 

1000       IF    (DEBUG. EO. I)    WR  IT E( 6, 1005)    ERROR 
1005       FORMATC    *LEAVING    DLFILE — ERR0R  =  ,,I1) 

RETURN 

END 

M 

•I 
M 
II 

n 

"  PROCESSOR  CALC  CALCULATES  GPA'S  FROM  VARIOUS  SETS  OF  GRADES: 

"  GRADES  RECORDED  IN  THE  FILE  BUT  NOT  INCLUDED  IN  GPA,  OR 

"  THE  UNION  OF  UP  TO  ANY  4  OF  THE  FOLLOWING: 

"  1)  ALL  COURSES  WITHIN  THE  MAJOR  AREA  OF  STUDY 

"  2)  ALL  COURSES  WITHIN  THE  MINOR  AREA(S)  OF  STUDY 

"  3)  ALL  COURSES  WITHIN  THE  MAJOR  AND  MINOR  AREAS  OF  STUDY 

M  4)  ALL  COURSES  WITHIN  A  SPECIFIC  DEPARTMENT 

"  5)  ALL  COURSES  PAST  A  GIVEN  SEMESTER 

"  6)  ALL  COURSES  PAST  A  GIVEN  ACADEMIC  STATUS 

H  7)  ALL  COURSES  WITHIN  A  GIVEN  NUMBER  OF  HOURS 

M  8)  ALL  COURSES  INCLUDING  AND  ABOVE  A  GIVEN  LEVEL  (E.G.,  100) 

"  THE  DEFAULT  VALUES  ARE: 

"  ALL  DEPARTMENTS, 

M  MAJOR,  MINOR,  AND  GENERAL  EDUCATION  COURSES, 

"         100  LEVEL, 

"  FROM  FRESHMAN  STATUS, 

"  FROM  ENTRY,  AND 

"  ALL  HOURS  COMPLETED 

"  GRADES  USED  IN  CALCULATIONS  ARE  A , B, C , D, E , AB . 

"  AB  IS  REPRESENTED  INTERNALLY  AS  G. 

■  GRADES  NOT  YET  INCLLDED  IN  A  GPA  ARE  FLAGGED  WITH 

"  AN  ASTERISK  (E.G.,  A*).   AN  'IP'  GRADE  CODE  STANDS 

"  FCP  • IN  PROGRESS'. 

N 
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SUBROUTINE  CALC (GPA ,  HOURS , ERR  OR ,NUM, PRI NT, SET ) 

INTEGER*2  LLI NE( 72 ) , CBLOCK ( 56, 12) , GIB2 ( 20) ,HEAD=R(32) ,CHEKOV< 12),% 

GRADE,  UK,  AB/'AB'/.Giej/^G*  .'ES'DS'CS'BS'A*/,* 

IP/»IP»/ 
INTEGER  ERROR, SUM1,SUM2,SUM3, SUM*, DEPT( 12 ) , DDATE, AUX, % 

FINI ,S,T,DEBUG/0/,CUT0FF,END,PRINT,SET,H,HR,L0NG(6)/4*8,2*3/,% 

Li(2)/2,l/,L2(2)/2,l/,LLt3),TYPE(6)M*5,2*6/,PP,K0L/l/ 
REAL*8    VEC1260) ,OUT , SLAVE ( 4 ) , DCODE < 12 ) ,GI B8 (5 ) , A< 3 ) / • MA JOR • 9% 

•MINOR1, •     »/,B< 4) /'FRESHMAN* ,  • SOPHOMORE'  ,' JUNIOR* , 'SENIOR •/,% 

KEY<6)/*TYPE*,'DEPT'  ,' STATUS'  ,  •  SEMESTERS  'HOURS1  ,* LEVEL'  /  9% 

N0DESC4) ,GIB4*4(16) 
COMMON    HEA0ER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 

VEC, SLAVE, NODES, LL 
IF    (DEBUG. EQ.l)    WRITE<6,5)    SET 
5  FCPMATP    *ENTERING   CALC — SET=',I1) 

it 

«  INITIALIZATIONS 

it 

PP=PRINT 
NUMBER=0 
DO    7    J=l,12 
7  DEPT(J)=0 

MM=0 
IFAIL=0 
NUM=0 
HOURS=0.0 
GPA=0.0 
NMAJOR=0 
T  =  0 
SUM  1=0 
SUM2=0 
SUM3=0 
SUM4=0 
KK=1 

S=0 
•• 

"  IF    SET   =     1,    THEN    LEVEL,    DDATE,    ETC.    FROM    THE    LAST 

"  USE    OF    THE    PROCESSOR    ARE    TO    BE    USED    AGAIN 

•i 

IF    (SET.NE.O)    GO    TO    1900 
1  =  0 
•• 

"  THERE    ARE    IEND    DEPT  .   BLOCKS    USED    IN    THIS    FILE 

n 

IEND=GIB2(10) 

ODATE=0 

IT0P=3 

IBOT=0 

LEVEL=100 

M 

"  FIND    CURRECT    SEMESTER 

M 

CALL  OPEN( I, 'DATES' , 'INPUT' ) 
READIltlO)  NOW 
10     F0RMATU5) 

CALL  CLOSEtl) 
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"  READ    SEARCH    CLASS    OESCRIPT IONC S ) 

it 

CALL    OPENC  12, 'BUFFER',  UNPUTM 

N 

"  FIRST    LINE    IN    BUFFER    IS    AN    OLF    COMMAND, 

"  NOT    A    DATA    LINE    FOR    THIS    PROCESSOR 

•i 

READ(12,20)    LLINE 
17  READU2,20  ,END=1000)    LLINE 

20  FORMATC72A1) 

1  =  1 

M 

"  DETERMINE    TYPE    OF    DESCRIPTION 

ti 

CALL    CCNVRT(OUT,5,LL  IN E, 8, AUX, 1 1 , ERROR, £29901 

DO    30    J=l,6 

IF  (OUT. EO. KEY! J)  )  GC  TO  40 
30     CONTINUE 

GO  TO  2800 
40     IF  CJ.EQ.4)  GO  TO  400 

MM=1 
•• 

"       CCNVERT  THE  DATA  FIELD 

n 

50     CALL  C0NVRT(OUT,TYPE(J) , LLINE, LONG C J ) , AUX, 11* 10*MM, ? 

ERROR, £29931 
n 

"       SET  THE  STRATEGY 
n 

GO  TO  (  100, 200, 300, 4C0, 500, 600) , J 

N 

"  MAJOR    AND/OR    MINOR    CCURSES 

ii 

100  DO    115    K=l,3 

IF     IACK).EQ.0UT)    GO    TO    120 
115         CONTINUE 

GO    TO    2800 
120  IF    C0UT.EQ.AC3>)    GO    TO    170 

IF     CLICK). LT.  ITOP)     IT0P  =  L1(K) 

IF     (L2(K).GT. IBOT)     ieOT=L2CK) 

KK=KK+1 

MM=2 

IF     CKK.LE.2)    GO    TO    50 

GO    TO    17 

170  IF    (KK.EO.l)    GO    TO    2800 

GO    TO    17 
•i 

"  COURSES    IN    A    SPECIFIC    DEPARTMENT 

200         DO    250    K0L  =  1,  IEND 

IF     (OUT.EO.DCODE(KOL))     GO    TC    270 
250         CONTINUE 

WRITEC6,260)    OUT 
260         FOPMATC     "«,A8,,H     IS    NOT    A    DEPT.    USED    IN    THIS    FILE') 

GO    TO    3000 
270  I=KCL 

IEND=KOL 
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GO  TO  17 
ii 

"       COURSES  AFTER  REACHING  A  SPECIFIC  ACADEMIC  STATUS 
ii 

300    DO  350  K=l,4 

IF    (OUT.EQ.B(K) )    GO    TO    370 
350         CONTINUE 

GO    TO    2800 
370         K=GIB2(K+2) 

IF     (K.EQ.O)    K=N0W+10 

IF     (K.GT.DDATE)     DDAT E=K 

GO    TO    17 
•i 

"  COURSES    TAKEN    DURING    OR    AFTER    A    GIVEN    SEMESTER 

n 

400    CALL  TIMES (K, LL INE,2  1,31 , KR , ERROR, £3000) 

IF  (K.GT.DDATE)  DDATE=K 

GO  TO  17 
•i 

••       COURSES  WITHIN  THE  LAST  SC-MANY  HOURS 

GIB2I15)  IS  THE  NUMBER  OF  COURSES  COMPLETED 


•i 


500         IF    (GIB2(15).EQ.0)    GC    TC    3000 
FINI=0 
H=0 
HR=AUX*2 


FIND    LAST    HR    HOURS    WORTH    OF    CREDIT    BY    SEARCHING 
BACKWARDS    IN    TIME    THROUGH    THE    FILE. 
INITIALIZE    CUTOFF    DATE    TO    PRESENT. 
SET    END    TO    STUDENT'S    ENTRY    DATE 


CUTOFF=NOW 

END=GIB2(2) 

510 

DO    525    J=i,IEND 

K2  =  (DBL0CK(3,  J )-l)*5*7 

•i 

DO    525    Kl=7,K2,5 

•• 

PEJECT    THIS    COURSE     IF 

NOT 

ii 

REJECT    THIS    COURSE     IF 

NOW 

it 

M 

PEJECT    THIS    COURSE     IF 

NOT 

TAKEN    IN    SEMESTER    AT    DATE    CUTOFF 

IN    PROGRESS 

YET    INCLUDED    IN    GP A 


IF     (08LrCK(Kl*l, J). NE. CUTOFF)    GO    TO    520 

GRADE=DBL0CK(K1+3,J) 

IF    (GRADE. EQ. IP)    GO   TO   520 
ii 

"  LOOK    FOR    *     IN    RIGHT    BYTE 

M 

I JK =GR ADE- (GRADE/ 256-25 5*2 56- 1)*2 56 

IF  (IJK.EQ.92)  GO  TO  520 

H=H+DBL0CK(K1*2,  J) 
•i 

"  GONE    BACK    FAR    ENOUGH    IF    H.GE.HR    OR 

H  IF    HAVE    BACK-TRACKEC    THROUGH    TO    ENTRY    DATE 

H  (I.E.,    CUTOFF. EO. END) 

H 

520         IF    (CUTOFF. LE. END)    GC    TC    522 
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IF     (H.LT.HR)    GO    TO    525 
522  FINI=1 

525         CONTINUE 

IF    (FINI.EQ.O)     GO    TO    540 

IF  (CUTOFF. GT.DDATE)  DDATE=CUTOFF 

GO  TO  17 
540    CUT0FF=CUT0FF-1 

IF  CMOD(CUTOFF,10).EQ.O)  CUT0FF=CUT0FF-7 

GO  TO  510 
it 

"  ADVANCED    LEVEL    COURSES 

N 

600  IF    (AUX.LE.O)    GO    TO    2800 

LEVEL=AUX 

GO    TO    17 
ft 

"  INCLUDE    NEW    GRADES     IN    GPA 

1000       IF     (I.NE.O)    GO    TO    1900 

1  =  1 

T=l 

IACV=0 

GO    TO    1900 
n 

"  UPCATE    GIB4,     GIB2 

n 

1050      GIB4(2)=GIB4(2)+H0URS 

GIB4( 1)=GIB4( l)+H0URS-IFAIL*.5 

GIB4(3)=GIB4(3)+IADV*.5 

GIB4(8)=GIB4< 8)+SUMl*.5 

IF     (GIB4(2).NE.0.0)     CI B4( 6 )=GIB4( 8) /GI B4< 2 ) 

GIB41  10)  =  GIB4(10)«-SUP3*.5 

GIB4(9)=GIB4(9)+SUM4*.5 

IF    (GIB4(9).NE.0.0)     GI  B4(  7) =GI B4( 10 )/G I B4( 9) 

GIB2< 15)=GIB2( 15)+NUM 

GIB2( 14)=GIB2( 14)*NMAJ0R 

GIB2(13)=GIB2(13)+NUN 

PP=0 

T  =  2 

H 

"  UPDATE    DEPARTMENT    INFORMATICN    BLOCKS 

ti 

1  =  1 

1070       SUM1=0 

SUM2=0 

NUMBER=0 

IFAIL=0 

IF     (DEPTH  J.EQ.l)     GO    TO    2050 

GO    TO    1200 
1080       DBLOCK( 1, I )=SUM2-IFAIL 

DBLOCK (2, I )  =  DBLOCK(  1, I ) 

CBL0CM5,  I  )  =  SUM1 
1200       1=1+1 

IF     (I.LE.IENO)     GO    TO    1070 

GO    TO    3000 

H 

"  FIND    GPA    OF    SEARCH    CLASS 
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«  ITCP=3    ->    NOT    RESTRICTED    TO    MAJOR    AND/OR    MINOR 

M 

1900   IF  (DEBUG. EO.l)  WR ITE( 6, 19101  LE VE L» DDATE, I  TOP , IBOT , I , I  END 
1910   FORMATP  LIMITS:  LEVEL  =  ,tI3,t    DDATE=«,I5,X 

•  ITOP-SIli1    IB0T=»,I1,»    DEPTS  "t^t"  TO  »,I2) 
2000   IF  (IT0P.EQ.3)  GO  TO  2050 

i* 

"       RIGHT  TYPE? 
n 

S=DBL0CK(4,I) 

IF  (S.LT.ITOP)  GO  TO  2700 

IF  (S.GT.IBOT)  GO  TO  2700 

2050  IF  (DEBUG. EQ.l)  WRIT  E(6  ,205  1)  DCODEU),I,% 

(DBL0CK(K3,I),K3=1,6) 

2051  FORMATM  NEW  DEPT .= • , A8, • CBLOCK ( l->6, • , 12, • )= • » % 

614) 
K2=(DBL0CK(3, M-l )*5+7 
DO  2500  K1=7,K2,5 
K3=KH-4 

IF  (DEBUG. EQ.l)  WRIT E(6, 2055)  < DBLPCK ( K4t I ) »K4=K1 ,K3) 
2055   FORMATt*  COURSE  =  ' , I  3  ,»   DATE=,,I5,»   HOUR S*2= • , 12 ,% 

•  GRADE=•,A2,•   CCDE=»,I3) 
n 

w       WAS  THE  COURSE  TAKEN  TCC  LONG  AGO? 
ti 

IF  (DBL0CK(KH-1,I).LT.CCATE)  GO  TO  2500 
n 

M       IS  THE  COURSE  TOO  LCW-LEVEL? 
it 

LVL=DBL0CK(K1, I) 

IF  (LVL.LT. LEVEL)  GO  TO  2500 

GRADE=DBL0CK(Kl+3, I ) 

DO    2100    J=l,6 

M 

"       HAS  THIS  COURSE  BEEN  INCLUDED  IN  A  GPA  YET? 
M       (IS  IT  AtB,C,D,E,OR  AB?) 


IF     (T.EQ.l )    GO    TO    2080 

2060       IF    (GRADE. NE.G( J) )    GO    TO    2100 
ti 

"  THIS    COURSE    BELONGS    IN    THE    DESIRED    GPA 

it 

H=DBL0CK(K1+2,I  ) 
SUM1  =  SUM1«-<J-1)*H 
SUM2=SUM2+H 

IF    (J.LT.3)    IFAIL=IFAIL*H 
NUMBER=NUMBER+1 
IJK=G( J) 

IF     (J. EO.l)     IJK=AB 

IF  (PP. EO.l)  WRITE(6,2063)  DCODE (I ) » DBLOCK (Kl ,  I )  ♦  I JK 
2063   FORMAT!*  USING  •,A6,I3,«  WITH  GRADE  »tA2) 
IF  (T.NE.l)  GO  TO  2500 


THESE  ARE  JUST-RECEIVED  GRADES — CHANGE  "*"  TO  "  » 

DBLCCMKl  +  3,1 )=G( J) 
DEPT( I)=l 


74 


IF  (LVL.GE.200)  IADV  =  IADV«-H 

H 

"       UPDATE  HOURS  AND  GRADES  IN  MAJOR,  IF  APPROPRIATE 

IF  (DBL0CM4,  I)  .NE.2  I  GO  TO  2500 

SUM3=SUM3+(J-1)*H 

SUM4=SUM4+H 

NMAJOR=NMAJOR-H 

GO  TO  2500 
2080   GRADE=GRADE-28 

GO    TO    2060 
2100       IF     (GRADE. LT. DBLOCK ( Kl+3, I » )    GR ADE=DRLOCK( Kl+3 , I ) 
2500      CONTINUE 

IF     (T.EQ.2)    GO    TO    1080 
2700       1=1*1 

IF    (I.LE.IEND)    GO    TO    2000 

1=1-1 

IF    (SUM2.EQ.0)    GO    TO    2520 

GPA=SUM1/FL0AT(SUM2) 

H0URS=SUM2*.5 
2520       MJM=NUMBER 

IF     (T-l)     3000,1050, 1C80 
2800       K=MM+2 

WRITE<6,2810)    OUT,K 
2810       FORMAT!*     ",,A8,«,»     IS    AN    IMPROPER    RESPONSE    FOP    FIELD    ',11) 
2990       ERR0P=1 

3000       IF    (PRINT. EQ.l)    WR IT E(6 , 3005)    GPA,  HOURS, NUM 
3005       FORMATS    LEAVING    CALC         GPA=»,F5.3,»       HOURS*' ♦ F6. 2 ,* 
•       NUM=»,I3) 

CALL    CLCSE(12) 

RETURN 

END 


« 

PROCESSOR    USERA    CCMFARES    THE    GPAS    OF    TWO  SETS    OF    STUDENTS — 

H  THOSE    WHO    TOOK    A    SPECIFIED   COURSE    BEFORE  TAKING    OTHER    COURSFS 

w  IN    A    GIVEN    DEPARTMENT,    AND    THOSE    WHO    DID  NOT    TAKE    IT 


SUBROUTINE    USERA ( ERR CR , FI N I ) 

INTEGER*2    LL I NE ( 72 ) , FEADER ( 32  I , CHEKOV( 12 ) , GI B2 ( 20) ,S 

DBL0CK(56,12) 
INTEGER    ERR OR, COL/- 1/, DEBUG/1/, SET, STAR T/0/,N( 2) /2*0/,% 

LL(3) ,FINI 
REAL*8    FILE(2)/«FILElf,,FILE2«/,GIB8(5) , VEC( 260 ) , SLAVE ( 4 ) ,f 

N0DES(4),VERB(2)/»fcITH« , • WITHOUT • /,DCODE ( 12 ) ,DEPT1,DEPT2 
PEAL    GIB4( 16) , G( 2 ) /2 *0. /,H ( 2 ) /2*0. / ,SDEV( 2 )/2*0./ 
COMMON    HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK,S 

VEC, SLAVE, NODES, LL 
IF     (DEBUG. EO.l)     WRITE(6,5)     FINI 
FORMAT!  •     *ENTERING    USERA — FINI-SU) 


IF    FINI    =    I    THEN    THIS 
GO    CALCULATE    THE    MEAN 


IS    THE    STATISTICS    WRAPUP    CALL 

AND    THE    STANDARD    DEVIATION    HOURS*GRADES 


IF    (FINI. EO.l)    GO    TO    1000 
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IF    (START. NE.O)    GO    TC    20 

M 

"  READ    THE    NAMES    OF    THE    COURSE    AND    DEPARTMENT    IN   QUESTION 

m 

CALL    OPEN( 12, 'BUFFER •»• INPUT*  ) 
READ(12,6)LLINE 

6  F0RMAT172A1) 

CALL    C0NVRT(DEPT1,5,LLINE,8,JUNK,31,ERR0R,£2150I 

CALL    CCNVRT(DEPT2,4,LLINE,8,NUM,41,ERR0R,£2150> 
•i 

"  THE    REMAINING    BUFFERED    INFCRMATION    IS    FOR    PROCESSOR    CALC 

"  ADDING    A    CALC-FORM    COMMAND    FOR    DFPT.    DEPT1 

M  CALC    IGNORES    THE    FIRST    LINE    IN    THE    BUFFER 

t» 

CALL    CL0SE(121 

CALL    0PEN(12, 'BUFFER  S'MOD*  ) 

WRITE<12,7)    DEPTl 

7  F0RMAT(10X,»DEPT' ,6X,A8) 
•i 

"       CREATE  FILE1  £  FILE2  TO  CLEAR  THEM  OUT 

"       GPA*HOURS  FOR  STUDENTS  WITHOUT  TEST  COURSE  GO  IN  FILEl 

"       GPA*HOURS  FOR  STUDENTS  WITH  TEST  COURSE  GO  IN  FILE2 

DO    15    1=1,2 

CALL    OPEN(  I,FILE{I»,fOUTPUTM 

15  CALL    CLOSE(I) 

START=1 

20  J=l 

if 

••  HERE,     K    IS    THE    NUMBER    CF    DEPARTMENT    BLOCKS    USED 

"  BY    THE    CURRENT    STUDENT 

N 

K=GIB2(10) 

IF     (K.EQ.O)    GO   TO    3000 

DO    30    1  =  1, K 

IF  (OCODEC  D.EQ.DEPT2)  GO  TO  35 

30     CONTINUE 
it 

"       HAS  TAKEN  NO  COURSES  IN  THE  SAME  DEPARTMENT  AS  THE  TEST  COURSF 
•t 

GO  TO  100 
35     KK=DBL0CK(3,I) 

DO  37  M=1,KK 

IF    (DBLOCK(2*M*5,I ).EO.NUM)    GO    TO    AO 
37  CONTINUE 

N 

"  HAS    NOT    TAKEN    THE    TEST    COURSE 

•• 

GO    TO    100 
n 

w       HAS  TAKEN  THE  TEST  CCURSE 

M 

40  J=2 

H 

"  IF    THE    STUDENT    HAS    THE    GIVEN    DEPARTMENT    IN    THE    SAME    COLUMN    AS    THE 

H  LAST    STDUENT    FILE    SEEN    BY    CALC,     THEN    THE    SEARCH    STRATEGY    USED    BY 

"  CALC    DOES    NIT    CHANGE — SET=1    TELLS    CALC    TO    LEAVE    THE    BUFFER 
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m  CLOSED    ANO   REUSE    ITS   OLD    SEARCH    STRATEGY 

M 

100         SET=1 

00    130    1=1, K 

IF  IDC0DE1 II.EQ.DEPT1)  GO  TO  150 

130    CONTINUE 
it 

STUDENT  HAS  NOT  TAKEN  ANY  COURSES  IN  THE  GIVEN  DEPARTMENT 

N 

GO  TO  3000 

N 

"  IF    I=COL    THEN    LEAVE    SET  =  i 

w 

150         IF     U.EQ.COL)     GO    TO     170 

SET  =  0 

COL=I 
•i 

M  FIND    THE    DESIRED    GPA 

ii 

170         CALL    CALCIGPA, HOURS, ERROR, NUMB, 1, SET) 
•• 

H  FCRGET    ABOUT    THIS    STUDENT    IF    HE    HASN'T    TAKEN    ANY    COURSE 

"  OF    INTEREST    IN    THIS    COMPARISON 

H 

IF    (NUMB.FO.O)    GO    TO    3000 

GR=GPA*HOURS 

G( J)=G(J)*GR 

H(J)=H{J)+HOUPS 

N< J)=N(J)*i 


SAVE    THIS    STUDENT'S    GRADES*H0URS    FOR    USE     IN    FINDING    THE    STANDARD 
DEVIATION    AFTER    THE    MEAN    IS    KNOWN 


CALL    OPENl  J,FILE(  J),  'MCDM 

WPITE(J,200)    GR 

200  F0RMAT(F10.3) 

CALL    CLOSE(J) 
«i 

GO  GET  THE  NEXT  STUCENT  FILE 
n 

GO  TO  3000 

M 

w       FIND  THE  AVERAGE  COMPOSITE  GPA  FOR  EACH  CLASS 

N 

1000       IF     (N(l).NE.O)    G(l)=G( 1)/N(1) 
IF     (N(2).NE.O)     G(2)=G(2)/N(2) 
DO    1500    1=1,2 
CALL    OPEN( I,FILE(I ), MNPUT* ,K) 


FIND    THE    STANDARD    DEVIATICNS    FOP    EACH    CLASS 

SEE     IF    FILE(  I  )     EXISTED 

IF    (Nl I ).E0.0)    GO    TO    1500 

K=NU) 

DO    1400    J=1,K 

REACH  ,200,  EN0=1500I    GR 
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SDEV(  I)  =  SDEV(  1 1 -KG  (  I  )-GR)**2 
1400   CONTINUE 
1500   CALL  CLOSE(I) 

DO  2000  1=1,2 

SDEV< I)=SQRT(SDEV(I)  ) 
2000      WRITE(6,2100)    N(  I  ) ,  VERB (I) , DEPT2 , NUM,G ( I ), SDEVC I) 
2100      F0RMAT(1X,I4,»    STUDENTS    ',A8,A5,I3/'    GRADES*HOURS ( AVE) =• ,% 

F8.3,5X, 'STANDARD    CEVIATICN=' ,F8.3) 
ii 

"  RE-INITIALIZE    THE    PROCESSOR    FOR    FURTHER    USE 

n 

START=0 

DO    2140    1=1,2 

N(I)=0 

GU)  =  0. 

SDEVU  )=0. 

H(  I  )  =  0. 
2140      CONTINUE 
2150      CALL    CL0SE!1,2,12) 

IF    (ERROR. EQ. 10)    ERR0R=1 
3000       IF     (DEBUG. EQ.l)    WRIT E( 6,3200 )    ERROR 
3200       FORMAT! •    *LEAVING    USERA — ERR0R=',I1) 

RETURN 

END 
n 

•• 

M 
It 

SUBROUTINE    DUD 
RETURN 

END 
n 
n 
ii 
« 

H       OLF  SUBPROGRAMS 

H 

w  SUBROUTINE    LOAD    LOAOS    FILE    NAMED    NAME     INTO    DIRECTORY    SELECTED 

«  BY    LEVEL.       IF    NAME=LAST( LEVEL ) ,    PROCESSING    IS    SKIPPED 

"  IF    C0PY=1,    FILE    NAMED    LAST(LEVEL)     IS    COPIED    TO    DISC    BEFORE    FILE 

"  NAMED    NAME    IS    LOADEC    INTO    CORE 

•i 

SUBROUTINE    LO AC ( LEV E L, NAME, COPY, L AST, VECTOR ,L ENGTH, NAME2,KARD ) 

REAL*8    NAME,VECT0R(260) ,LAST( 4 ) ,NAME2 

INTEGER    COPY, Ll(3)/1, 201, 241/, L3(3) /O, 20,0/, LENGTH(3) , DEBUG/0/ 

IF    (DEBUG. EQ.l)    WRITE(6,1)     LEVEL, NAME 
1  FORMAT!1    CENTERING    LCAC — LEVEL=',I1,% 

•,     TO    FIND    »,A8) 

IF    (NAME.EQ.LAST(LEVED)    GO   TO    100 

IF  (KARD.EQ.l)  WRITE(6,4)  LEVE L, NAME2 , NAME 
4      FORMAT!'  NOW  LOADING  LEVEL-', II, •  DIRECTORY  • , A8, •  {',A8,')') 

J=L1(LEVEL) 

IF  (COPY.EQ.O)  GO  TO  50 

IF  (DEBUG. EQ.l)  WRITE(6,8)  LAST(LEVEL) 
8      FORMAT!'  MUST  COPY  FILE  *,A8,»  FIRST') 

CALL  0PEN(1,LAST(LEVEL), 'OUTPUT* ) 

K=J*-L3(  LEVEL)  +L  ENGTH  (LEVEL  )-l 
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WR I  TEC  1, 10) LENGTH ( LEVEL) ,( VECTOR (I >,I=J,K) 
10  F0RMATCA4/U0A8)) 

CALL    CLOSE(l) 

COPY=0 
50     CALL  OPENCi, NAME, 'INPUT' ) 

READll,55)  M 
55     F0PMATCA4) 

LENGTH(LEVEL)=M 

K=J+M-1+L3(LEVEL) 

IF     (M.EO.O)     K=J+L3(LEVEL) 

RE  AC (1,60) (VECTOR!  I)  ,I=J,K) 
60     F0RMATU0A8) 

LAST(LEVEL)=NAME 
100    IF  (DEBUG. EQ. I)  WRITE(6,105) 
105    FORMATS  ^LEAVING  LCAD' ) 

CALL  CLOSE(l) 

RETURN 

END 
•• 

ti 

N 
W 

M       SUBROUTINE  OUTPUT  PRINTS  STATUS  OF  SYSTEM  JUST  BEFORE 
"       INVOKING  (OR  SKIPPING)  THE  CURRENT  PROCESSOR 

SUBROUTINE  OUTPUT (I , PROC, BATCH, DUPL IC , LAST , J ,GI B8,% 
LINE, HEADER, I  START  ,LEN ,NAME2 ,0K) 

REAL*8  GIB8(5) , XXX ,YYY, PROC , DUPL IC (4) , LAST (4) ,NAME2,S 
KIND(3)/'CRRCLM« , • ADV ISOR ',' STUDENT • / 

INTEGER*2  HEADER ( 32 )  ,A ( 4 ) , B ( 4) /**•  • / , LINE ( 72  I  ,S 
QUOTE/""/ 

INTEGER  BATCH, DEBUG/C/, OK 

EQUIVALENCE  (  YYY,A(  1)), (XXX, BCD) 

0K  =  0 

IF  (DEBUG. EQ.l)  WRITE(6,1)  I 
1      FORMAT!'  *ENTERING  OLTPUT — ERR0R=',I2) 

K=I  +  1 

IF  (K.GT.2)  WRITE(6,5) 
5      FORMATCOSKIPPING  PROCESSING  STEP') 

GO  TO  (10, 10, 30, 50, 60, 67, 70, 80, 80, 90, 67, 100, 110), K 
10     WRITE(6,15)  PROC 
15     FORMAT! 'OABOUT  TO  ENTER  PROCESSOR  »,A8) 

IF  (K.EQ.i)  WRITE(6,17)  HE ADER, DUPL IC ( 3  ) 
17     FORMAT!'  STUDENT:  ',22A1,'     !',A8,')') 

IF  (K.EQ.2)  WRITE(6,20) 
20     FCPMATdX,  'STATISTICS  WPAPUP') 

CK=1 

GO  TO  1000 
30     WRITE(6,40) 
40     FORMAT!'*-'  ,24X,  •  —  TOC  MUCH  INPUT') 

0K  =  2 

GO  TO  1000 
50     YYY=GIB8(2) 

B(l)=A!2> 

B(2)=A(3) 

B!3)=A{4) 

WRITE (6,55) (HEADER (K),K  =  10, 29) , XXX, GIBS  13) 
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55     FORMAT!'  FILE  BELONGS  TO  I,20A1,«  CRRCLM= • t A8 , •  ADVI SOR  =  *  ,  A8) 

GO  TO  1000 
60     WRITE(6,65)  ( HE AOER ( M) , M=l , 9 ) , GI B8 (3 ) 

65     F0RMAT(1X,9A1,«  WAS  ACCESSED  ONLY  BECAUSE  SAB,'  ADVISES  • ,% 
•SEVERAL  CURRICULA.*) 

GO  TO  1000 

67  IENDMSTART-H.EN-1 

IF    CK.E0.6)    WRITE(6,68) (LINE! L ) , L=I ST ART, I ENO) , QUOTE 

68  FORMAT( •♦i,26X,»CANNCT    TRANSLATE    "•,21AD 
0K  =  2 

GO    TO    1000 
70  K=BATCHH-1 

IF     (K.EQ.O)    K=l 

WRITE16.75)  KIND(K) 
75     FORMATP  IMPROPER  COMMAND — SPECIFY  AT  OR  BELOW  ,,A7,1  LEVEL') 

0K=2 

GO  TO  1000 
80     K=J 

IF  (K.EQ.2)  K=4 

WRITE(6,85)    OUPLIC(J),J,LAST(J) 
85  FORMATP    FILE    ■  ,  A8 ,  •     IS    NOT    IN    LEVEL-SU.*    DIRECTORY     ',A8) 

GO    TO    1000 
90  WRITE(6,95)(LINEIK)  ,  M21  ,29)  ,  NAME2 

95  FORMATC     FILE    »,9A1,'    IS    NCT     IN    LEVEL-3    DIRECTORY    «,A8) 

GO    TO    1000 
100         WRITE(6,105) 
105         FORMATS    YOU    MUST    SPECIFY    A    NFW    PROCESSOR') 

0K  =  2 

GO    TO    1000 
110         KK=J+1 

WRITE(6,115)    KK,NAME2 
115         FORMATP    LEVEL-*. lit*    DIRECTORY    '.AS,'     IS    EMPTY*) 
1000       IF     (DEBUG. EQ.l)     WRI TE(6 , 10 10 ) 
1010      FORMATP    *LEAVING    OUTPUT*) 

RETURN 

END 
•t 

M 

•I 
tl 

"       FUNCTION  COMP: 

"  RETURNS    CCMP=    I    IF    KEY.GT.XMBER 

"  RETURNS    COMP  =    0    IF     KEY.EQ.XMBER 

"  RETURNS    C0MP=-1    IF    KEY.LT.XMBER 

n 

INTEGER    FUNCTION    COMP( PASS . LEVEL ♦ XMBER, KFY ) 
INTEGER    PASS,DEBUG/0/,T0P(2)/18,l/,B0T(2)M4,17/,l 

MATRIX(4),BEGIN(4)/4,8,12,16/ 
INTEGER*2    DIGIT(  16  )  ,  tsUM  (  44  )  /  •  $  *  ,  *  0  •  ,  *  1  •  ,  •  2*  ,  *  3*  .  * 
•4*,*5',*6*,*7*,*8*,*9*,*A*,*B*,*C*,*D*.'E*,*F*.I 
*     * , *A* ,*B*  ,*C* ,*C*,'E*  ,*F*  ,*G*  .*H*  ,» I* , *J* 


•N'.'O'.'P'.'O'.'R'.'S'.'T'.^U'.'V* 


REAL*8    KEY, XMBER, X.Y 

EQUIVALENCE(X,MATRIX(1) ),( Y, MATRIX! 3) ) 
IF     (DEBUG. EQ.l)     WRITE(6,5)     XMBER, KEY 
FORMAT(f    *ENTERING    CCMP—  XMBER=  •  ,  A8,  % 
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•  KEY=«,A8) 

COMP=0 

K=3 

IF    (PASS.EQ.l)    GO    TO    20 

PASS=1 

K=l 

KK=MOD!LEVEL,2)«-l 

ISTART=TOP!KK) 

IEND=BOT<KK) 

X=KEY 
20  Y=XMBER 

DO    60    I=K,4 

KKK=BEGIN<I ) 

MULT=0 

IF  (MATRIX! I) .LT.O)  *ULT=-i 

DI GIT (KKK)=MOD (MATRIX! I ), 256 )* 256*64 

MATRIX!  I  )  =  MATRIX(I  )/  256+255*^ULT*l  6777  2 16  4-MULT 

KKK=KKK-1 

00    60    J=l,3 

DIGIT! KKK)=MOD! MATRIX! I ) , 256) *256+64 

MATRIX! I )= MATRIX! I  J/256 
60     KKK=KKK-1 

00  100  1=1,8 

DO  70  J=ISTART, IEND 

IF  (DIGITU).EQ.NUM!  J)  )  GO  TO  75 
70     CONTINUE 
75     JJJ=I+8 

00  80  JJ=ISTART,IEND 

IF  IDIGITUJJ  ).EO.NUM!JJ)  I  GO  TO  85 
80     CONTINUE 
85     L=J-JJ 

IF  il.EQ.O)  GO  TO  IOC 

COMP=IABS!L)/L 

GO  TO  150 
100    CONTINUE 

150    IF  (DEBUG. EQ.l)  WRITE!6,170)  COMP 
170    FORMATS  *LEAVING  COKP — CCMP=«,I2) 

RETURN 


END 


SUBROUTINE    RENAME    RIGHT-SHIFTS    XXX    BY    TWO    BYTES    AND 
INSERTS    CHAR     INTO    THE    RESULTING    VACANCY 

IF     (DEBUG. EQ.l)    WPITE(6,1)     XXX, CHAP 

FORMAT!*    *ENTERING    RENAME — XXX=i,AP,1,     CHAR=»,A2) 

XXXX=XXX 

MULT1=0 

MULT2=0 

IF     (MATRIX!  1) .LE.O)     MULT1=-1 

IF     (MATRIX(2).LE.O)     FULT2=-1 

MATRIX!2)=MATRIX!2)/65  5  36+£5536*!6  5535*MULT2S 

♦  MOD  I  MATRIX! 1), 65 5 26 I )+MULT2 
MATRIX( 1)=MATRIX! 1 )/ (5  536+6 55  36*! 6 5535 *MUL TH-CHAR )♦ MULT 1 
XXX=XXXX 
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10 


ft 


IF     (DEBUG. EQ.l)    WRITE!6,10)    XXX 
FORMAT!'    *LEAVING    RENAME — XXX=',A8) 
RETURN 


n 
it 
w 
ii 

SUBROUTINE  REVISE  INSERTS  IDELETES)  KEY1  FROM  DIRECTORY! LEVEL ) 
IF  INCR=+1<-1).   IF  LEVEL=2,  IT  ALSO  INSERTS  (OELETES)  KEY2 


SUBROUTINE  REV  I SE( VECTOR ,LENGTH,KEY1, KEY2, PTR , LEVEL ,% 
INCR, LAST, ERR, NAME2) 

REAL*8  VECT0R(260),L/SST(A)  , CHOICE! 2)/'  INSERT',  'DELETE* /,? 
KEY1,KEY2, BLANK/'  »/,NAME2 

INTEGER  LENGTH!3),DUP,PTR,EPR,L1(3)/1,201,241/,L3(3)/0,20,0/,S 
LEN!3)/200,2Q,2G/,CEBUG/0/ 

KK=L3ILEVEL) 

IT0P=L1(LEVEL) 

KM=ITOP+LENGTHILEVEL  I+L3!  LEVED-1 

IBOT=KM-KK 

IF     (DEBUG. EQ.O)     GO    TC    10 

K=l 

IF     UNCP.EQ.-l)    K  =  2 

WRITE (6,5)     CHOICE! K) ,KEY1 , LEVEL , LAST ! LEVEL ), PTR 
5  FORMAT!'    *ENTERING    REVISE — TO    »,% 

A7,A8/*     IN    LEVEL-*  #11,* 
•    DIRECTORY    ',A8,»    AT    POSITION    ',13) 

DO    7    I=ITOP,KM 
7  IF     (VECTOR(I).NE. BLANK)    WRITE(6,297)     I, VECTOR! I) 

10  IF    (INCR.EO.-l)    GO    TC    100 

IF    (LENGTH  (LEV  EL).  ECO)    GO    TO    30 

IF    (LENGTH(LEVEL) . EQ .LEN( LEVEL ))    GO    TO    250 

DO    20    I=PTR,IBOT 

K=IBOT+PTR-I 

KK=K+L3(LEVEL) 

IF     (LEVEL. EO. 2)    VECTOR ( KK  +  1 )= VECTOR (KK ) 
20  VECTPR(K+1)=VECT0R(K) 

30  VECT0R(PTR)=KEY1 

IF     (LEVEL. EQ. 2)    VECTOR ( PTR +L31 LEVEL ) )=KEY2 

GO    TO    270 
100         DO    150    I=PTR,IBOT 

KK=I*L3(LEVEL) 

VECTOR (KK ) = VECTOR ( KK+1 ) 
150         VECTOR! I )= VECTOR! 1*1 ) 

GO    TO    270 
250         ERR=1 

INCR=0 

WRITF(6,260)     NAME2 ,L AST t LEV  EL ) ,KEY1 
260         F0RMAT(1X,A9, ' ( • ,A8, •)     IS    FULL — CAN"T    ADD    ',A8) 
2  70  LE NGTH  (  LEVEL  )=LENGTMLEV EL  )  +  I  NCR 

IF     (LENGTHILEVEL).NE.O)    GO    TO    285 

WRITE (6,280)  L EVEL ,NAME2, LAST  I  LEVEL ) 
280    FORMAT!'  LEVEL-', II, •  DIRECTORY  ',A8,'  !',A8,')  IS  NOW  EMPTY') 

KLH=L1!LEVEL) 

VECTOR IKLH)=BLANK 

VECT0RJKLH  +  L3ILEVEL)  )=BLANK 
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285         KM=KM+INCR 

IF    (DEBUG. EQ.O)    GO    TC    300 

WRITE(6,290)  ERR 
290    FORMATS  *LEAVING  REVISE — ERROR**,!!) 

DO  295  I=ITOP,KM 
295    IF  (VECTOR! I). NE. BLANK)  WRITE(6,297)  I.VECTOR(I) 
297    FORMAT(«  (  • , I  3, • ) • , 5X, A8) 
300    RETURN 

END 


"  SUBROUTINE    BISECT    DCES    BINARY    SEARCH    FOR    KEY    IN    DI RECTORY( LEVEL ) 

M  IF    KEY    IS    FOUND,    CUP=1    AND    PTR=POSITION    IN    FILE; 

■  IF    KEY    IS    NOT    FOUND,    DUP=0    AND    PTR=POINT    OF    INSERTION    IN    FILE. 

ii 

SUBROUTINE    BI SECT ( VECTOR .LENGTH, KEY, DUP,PTR,L EVEL , LAST ) 

REAL*8    VECT0R1260)  ,  KEY,  LASTU),  BLANK/1     •/ 

INTEGER    DUP, PTR, L ENGTH { 3), TOP (3)/ 0,200, 240 /,COMP,  DEBUG/0/,? 

L3(3)/0,20,0/ 
IPASS=0 
DUP=0 

ITOP=TOP(LEVEL) 
IB0T=IT0P+LENGTH(LEVEL)+1 
IF  (DEBUG. EO.O)  GO  TC  10 
J=IT0P+1 

K=IB0T-1+L3(LEVEL) 

WRITE(6,5)    KEY, LEVEL  ,LAST( LEVEL) 
5  FORMAT! •    *ENTERING    BISECT — SEARCHING    FOR    •,? 

A8,/«     IN    LEVEL-'. lit1    DIRECTORY    »,A8) 
DO    7    I=J,K 

7  IF     (VECTOR(I).NE. BLANK)    WRITE(6,8)     I,VECTOR(I) 

8  FORMAT!*     (»,I3,«)  «,A8) 

10  IF    (IT0P*-1.GE.I80T)     GO    TO    120 

PTR=(IT0P*IB0T)/2 

IF     (CCMPUPASS,  LEVEL  ,V  ECTOR  (  PTR  ) ,  KEY))     20,100,30 
20  IBOT=PTR 

GO    TO     10 
30  ITOP=PTR 

GO    TO    10 
100         DUP=l 
120  IF     (DUP.EO.O)     PTR=IBCT 

IF    (DEBUG. EQ.O)    GO    TC    300 

WRITE(6,200) 
200    FCRMAT(»  ^LEAVING  BISECT — •) 

IF  (DUP.EO.O)  WRITE(6,210)  KEY, PTR 
210    F0PMAT(»+«,30X,A8,'  BELONGS  AT  POSITION  ',13) 

IF  (DUP.EQ.l)  WRITE(6,220)  KEY, PTR 
220    FORMAT! •♦• ,30X,A8, •  FOUND  AT  POSITION  ■ v I  3 1 
300    RETURN 

END 


SUBROUTINE  TIMES  CONVERTS  FIELDS  STARTING  AT  PI  AND  P2 
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"       IN  LLINE  TO  A  COMPOSITE  DATE  INDICATING  BOTH 

"       YEAR  AND  SEMESTER.   THE  1ST  FIELD  IS  A  SEMESTER 

••       NAME  AND  THE  2ND  FIELD  IS  A  YEAR  NUMBER. 

N 

SUBROUTINE  TI MESCDAT E,L INE ,P1 , P2, FUTURE ,ERROR , *) 

INTEGER  Pit P2 , FUTURE, ERROR, DEBUG/O /,DA TE,L INE*2( 72) 

REAL*8  SEASON, CHOICE (4) /'SPRINGS 'SUMMER* , • FALLS • AUTUMN' /, OUT 

IF  (DEBUG. NE. 1)  GO  TC  10 

DATE=0 

Kl=Pl+7 

K2=P2+3 

WRITE (6,5) (LINE! I ) , I=P2 ,K2 ) , ( LINE ( I),I=P1,K1) 
5      FORMAT!'  *ENTERING  TIMES',? 

•  YEAR=' ,4A1,5X,'SEASCN=',8A1) 
10     CALL  C0NVRT(SEAS0N,5  ,L INE, 8, JUNK, PI , ERROR, G990) 

DO  30  1=1,4 

IF  (SEASON. EQ. CHOICEU)  )  GO  TO  50 
30     CONTINUE 

WRITE(6,35)  SEASON 
35     FORMATC  W',A8,'M  IS  NOT  A  VALID  SEMESTER  NAME') 

ERR0R=1 

GO  TO  1000 
50     IF  (I.EQ.4)  1=3 

CALL  C0NVRT(OUT,6,LINE,4,DATE,P2,ERROR,£990) 

DATE=DATE*10-H 

FUTURE=0 

CALL  OPEN( 1, 'DATES' , 'INPUT' ) 

READ(i,60)  NOW 
60     F0RMATII5) 

K= DATE-NOW 

IF    (NOW. NE. DATE)    FUTURE=I ABS( K )/K 

GO    TO    1000 
990  ERROR=i 

1000       IF    (DEBUG. EO.l)    WR IT E( 6, 1005  )    DATE, FUTURE 
1005       FORMATC    LEAVING    TIMES — YEAR*' ,15,"    FUTURE  =  ',I2) 

CALL    CLOSE( 1) 

IF    (ERROR. NE.O)    RETUPN    1 

RETURN 

END 
ii 

it 

ii 

n 

"  SUBROUTINE    CONVRT    CCNVERTS    LEN    CHARACTERS    STARTING    AT    LINE(START) 

"  (CCNVEPSION      TYPE    DETERMINED    BY    VALUE    OF    ITYPE): 

"  1)    TO    NAME    OF    STUDENT    FILE    (SSN    IN    HEXADECIMAL) 

"  2)    TO    BASIS    FOR    CURRICULUM    FILES     (DECIMAL) 

"  3)     JUST    CHECKS    FOR     INVALID    CHARACTERS 

"  4)     TO    DEPARTMENT    NAME    (IN    OUT)    £    COURSE    #     (IN    AUX ) 

"  5)    TO    BASIS    FOR    DEPARTMENT    FILE    NAMES 

"  OR    TO    AN    ADVISOR'S    NAME     (ALPHABETIC) 

"  6)    CONVERTS    CHARACTER    TO    DECIMAL    NUMBER    (IN    AUX) 

"  7)    CONVERTS    ¥    IN    AUX    TO    HEXADECIMAL    FILE 

"  NAME    IN   OUT 

SUBROUTINE  CONVRT (OUT, I TYPE, L INE, LEN, AUX, START, EPR ,* ) 
INTEGER*2  IN( 20 ) , LI NE( 72) , NUMBER ( 1 1 ) /'0 • , 'IS^S^SS 
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• /,ALPHA(30)/«A« ,% 

I'lMS'J'f'K'i'L'  ,»M»  , 
,tpi t»Qi ,«R»,»S«,«T»  f'US ■V,t 'H'i'X'i 'Y't 
't'  ,  •  •  ,  •♦  '»  *  •'  *♦  »-* /,ITEMP(2)  ,LT, BLANK, DOLLAR/' 
QUOTE/1  "V 

INTEGER  MATRIX12) ,HEX,AUX, START, DEBUG/0/,  ERR 

REAL*8    OUT,FLAG/•????????•/,XXX,CLEAR(5),BL/,     •/ 

EQUIVALENCE    (MATRIX!  1), XXX 1,1 ITEMP( 11, IT),? 
(  BLANK,  ALPHA  (27)  ),  ( IN(  1 )  ,CLE  AR  (  1)) 

M=0 

ERR=0 

LLEN=LEN 

XXX=0.000 

HEX=268435456 

IF     (LLEN.GT.201    LLEN=20 

DO    2    1=1,5 

CLEAR( I  )  =  BL 

K=START 

DO    5    I=1,LLEN 

IN(I)=LINE(K) 

K  =  K  +  1 

IF     (DEBUG. EQ.l)    WRITE(6,6)     ITYPE,IN 
IRMAT(»    *ENTI 
•CONVERTING 

GO    TO    (10, 500, 1000, 1700, 500, 10, 60), ITYPE 
10  KUM=0 

DO    50    I=1,LLEN 

LT=IN(I ) 

DO    30    J  =  l, 10 

IF  (LT.EO.NUMBER(J) )  GO  TO  40 
30     CONTINUE 

GO  TO  2500 
40     NUM=NUM*10+J-1 
50     CONTINUE 
60     IF  (ITYPE. EQ. 7)  NUM=AUX 

AUX=NUM 

IF  (ITYPE. EQ. 7)  GO  TC  70 

IF  (ITYPE. NE. I)  GO  TC  3000 
70     DO  100  1=1,2 

DO  100  J=l,4 

M=8-2*J 

L=NUM/HEX 

NU^=NUH-L*HEX 

N=16**M 

IF  (L.LE.9)  MATRIX!  I  )  =  MATR  IX(  I  )+N*( L+l 5*16) 

IF  (L.GT.9)  MATRIXU  )  =  MATRIX(  I  )*N*(  (L-9)«-12*16) 
100    HEX=HEX/16 

GO  TO  3000 
500    L=l 

DO  600  1=1,8 

LT=IN(  I  ) 

IT=0   - 

ITEMP(2)=LT 

IF  (ITYPE. NE. 2)  GO  TC  527 

DO  525  J=l,ll 

IF  (LT.EQ.NUMBER( J) )  GO  TO  540 
525    CONTINUE 
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GO  TO  2500 
527    00  530  J=l,27 

IF  (LT.EQ.ALPHA(J)  )  GO  TO  540 
530    CONTINUE 

GO  TO  2500 
540    IF  (I.EQ.5)  L*2 

IF    (I.EQ.5)    HEX=268435456 

MATRIX (L)=MATR I X(L  ) +  UT-64) /256*( HEX/16) 

HEX=HEX/256 
600         CONTINUE 

IF    (ITYPE.EQ.4)    GO    TC    1850 

GO  TO  3000 
1000   DO  1200  1=1,20 

LT=IN(I) 

DO  1100  J=l,30 

IF  (LT.EQ.ALPHA(J))  GO  TO  1200 
1100   CONTINUE 

GO  TO  2500 
1200   CONTINUE 

GO  TO  3000 
1700   DO  1800  IPT=1,6 

DO  1750  J=l,26 

IF  (IN(IPT).EQ.ALPHA(J) )  GO  TO  1800 
1750   CONTINUE 

GO  TO  1820 
1800   CONTINUE 

GO  TO  2500 
1820   LLEN=IPT-i 

K=9 

DO  1830  I=IPT,8 

IN(K)=IN(I  ) 

IN( I )=BLANK 
1830   K=K*-1 

GO  TO  500 
1850   L=IPT+2 

K=9 

DO  1910  1=7,9 

IN(I )=IN(K) 
1910   K=K*1 

N0N0=NUMBER(1) 

DO  1915  1=1,6 
1915   IN(I)=NCNO 

LLEN=9 

GO  TO  10 
2500   XXX=FLAG 

ERR=10 

WRITE (6,2600) (  IN(  I ),  1  =  1 ,LLEN) , QUOTE 
2600       FORMATP    CANNOT    TRANSLATE    MS21A1) 
3000      OUT=XXX 

IF    (DEBUG. EQ.l)    WP I T E( 6,3005)    OUT,AUX 
3005      FORMAT(«    *LEAVING    CONVRT — CUT=»,A8,% 
•  AUX=«,I10) 

IF    (ERR.NE.O)    RETURN    1 

RETURN 

END 
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•i 

"  OLF    UTILITY    PROGRAMS 

n 

"  DREDIT    CREATES    AND    DELETES    DI RECTCRY    FILES 

M  SUBPROGRAMS    INVOKED    IN    CRECIT    ARE    SHOWN    IN    THE   OLF    LISTING 

•• 

REAL*8    CURRIC/*CURRIC*/,LAST(  4) /4* 'DUMMY* / ,X, Y, Z ,S 

VECTOR (260) , NAME, ENTRY (2 ), VERB, BLANK / •    •/, ACTION ( 3) % 
/•INSERT*, 'DELETE* , • NEXT* /, LIST( 2 ) /• CRLI ST* , »DLLIST*/,S 
BUF(21)/21*«     */,DU»'MY/*DUMMY*7,CH0ICE(2) /*FOUND*,*IS    NOT*/,? 
THING 

REAL*4    V1(2)/*INT0*,  'FROM* / , ANSI 3) /• 1' ,*2* ,*DONE*/ 

INTEGER  ERR0R,PTR,DUP,TYPE(3)/2,5,1/,ACT(2)/1,-1/,S 
AUX0UT,LENGTHI3) ,CCPYI2 ) /2*0 /,LEN ( 3) /8, 8 , 10/, % 
ZERO/0/, IRUN/0/,KIND(2)/5,2/,V(2)/*  *,*DEST*/,% 
LLEN(2)/21,2/ 

INTEGER*2  INI  20 ) ,LI NE( 72 ) , $$/* $$ • / , A (4 )  ,ONE/* I • /, % 
BL/*  •/ 

C0MPLEX*16  W0RDS(2)/*CURRICULUM  ¥*,*NAME  AND  SSN*/,? 
BUFF, CLEAR/*  •/ 

EQUIVALENCE  (  IN(1),L  INEI 1 ) ) , (NAME, A ( 1 )  ),% 
IBUFI 1) ,BUFF) 
it 

"       LOAD  LEVEL-1  DIRECTORY  CURRIC 
ti 

CALL  LOAD( 1 ,CURR IC , 0  ,LAST , VECTOR, LENGTH , CURR IC ,0) 
5      M=l 
n 

»       REOUEST  THE  NAME  OF  THE  TO-BE-EDITED  FILE 
•• 

WRITE(6,10) 
10     FORMAT! •  TYPE  LEVEL — 1  OR  2  COR  DONE)  AND  NAME  OF  FILE*,? 
•  TO   BE  EDITED*/) 

READ(5,15)  ANSWER, IN 
15     FCRMAT(A4,6X,20A1) 

DO  20  LEVEL=l,3 

IF  (ANS(LEVEL).EO. ANSWER)  GC  TO  40 
20     CONTINUE 
23     WRITE(6,25) 

25     FORMAT! •  SORRY — COULCN**T  UNDERSTAND  THAT*) 
27     GO  TO  (5,100)  ,M 
40     IF  (LEVEL. EQ. 3)  GO  TC  500 

CALL  CCNVRT(NAME,KINC(LEVEL),LINE,8,AUXOUT,l,EPROR,&27) 

IF  (LEVEL. EQ.2)  GO  TC  45 

IF    (NAME. NE. CURRIC)     GO    TO    23 

GO    TO    100 

"  PREFACE    CURRICULUM    CODE    WITH    $$ 

45  CALL    RENAME(*$,NAME) 

H 

"  IS    THE    REQUESTED    FILE    KNCWN? 

•i 

CALL     BISECT (VECTOR, LENGTH, NAME, DUP,PTR,  1,LAST) 
IF     (DUP.EQ.l)     GO    TO    90 
WRITE(6,50)    A(2),A(3),A(4) 
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50     F0RMAT(1X,3A2,«  IS  A^  UKKNCWN  CURRICULUM') 
GO  TO  5 

N 

■  LOAD    THE    TO-BE-EOITED   FILE 

n 

90  CALL    L0A0(2, NAME, CCPY<2), LAST, VECTOR, LENGTH, NAME, 0) 

100         M=2 

N 

M       OETERMINE  THE  TYPE  CF  EDITING  REOUIRED 

••       DETERMINE  THE  NAME  OF  THE  FILE  TO  BE  INSERTED  (DELETED) 

it 

WRITE(6,U0)  WORDS(LEVEL) 
110    FORMATC  TYPE  ACTION,  »,A12) 

READ! 5, 120)  VERB, ( IN ( I ) , 1= I, 8  I , ( IN( I ) ,  1  =  12 ,20) 
120    F0RMAT(A8,2X,8A1,2X,^A1) 

DO  130  1=1,3 

IF  (VERB. EO. ACTION! I ))  GO  TO  150 
130    CONTINUE 

GO  TO  23 
•* 

•»       IF  TYPE  OF  EDITING  =  NEXT,  GO  GET  THE  NAME  OF  THE 
«       NEXT  FILE  TO  BE  EDITED 

H 

150    IF  (I.E0.3)  GO  TO  5 

INCR=ACTII) 

J=0+LEVEL 

K=l 
160    CALL  CONVRT(ENTRY(K)  ,TYPE( J) ,L INE,  LEN ( J ) , AUXOUT,? 
(K-l)*10+l, ERROR, C27) 

J  =  3 

IF  (LEVEL. NE. 2)  GO  TC  200 

IF  (K.E0.2)  IN(11)=BL 

IF  (K.EQ.2)  GO  TO  200 

K=2 
ii 

M       ADD  1  BILLION  TO  THE  ADVISOR'S  SSN  TO  MAKE  ADVISOR  FILENAME 

•*       CLEARLY  DISTINGUISHABLE  FRCM  STUDENT  FILENAME 
if 

IN(U)=ONE 

GO  TO  160 

200  IF     (LEVEL. EQ.l)    CA LL    R ENAME ( $$,ENTRY( 1) ) 

it 

"  DOES    THE    FILE    TO    BE    INSERTED    (DELETED)    EXIST? 

n 

CALL    BISECT(VECTOR, LENGTH, ENTRY( 1) ,OUP , PTR , LEVEL , LAST ) 
IF    (I-DUP.EQ. I)    GO    TO   220 
i, 

n  FILE    EITHER    EXISTS    WHEN    IT    SHOULDN'T    OR 

w  DOESN'T    EXIST    WHEN     IT    SHOULD 

M 

WRITE (6,205)  ENTRY ( 1 ) , CHO ICE(  I ) , LA  ST ( LE VEL ) , VERB 
205    F0RMAT(1X,A8,IX,A6,»  IN  DIRECTORY  ',A8,S 
•  CAN"T  »,A6,'  IT') 

GO  TO  100 
220    IF  (LEVEL. EQ.l)  GO  TC  245 

IF  (INCR.EO.-l)  GO  TD  245 


II 

FIND   THE 

•1 

OWNER    OF 

II 
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"       CREATING  A  NEW  FILE — HAKE  SURE  THAT  THE  PROPOSED 

"       FILE  DOES  NOT  EXIST  ON  ANOTHER  BRANCH  OF  THE  OLF  TREE 
it 

CALL  OPEN(  1,ENTRY(2)  ,MNPUT«,N) 
IF  (N.NE.O)  GO  TO  243 

H 

"  THE    FILE    EXISTS 

n 

PEA0(i,270)    N 

IF    (N.EQ.O)    GO    TO    235 

n 

NAME  AND  CURRICULUM  OF  THE  PRESENT 
THE  DISPUTED  SSN  FROM  A  STUDENT  FILE 

READ(1,275)  X 

CALL  OPEN(2,X,» INPUT') 

REAC(2,230)  Y,Z 
230    F0RMAT(40X,2A8) 

CALL  CL0SE(2) 

GO  TO  240 
•• 

"  IF    THIS    IS    A    NEW    ADVISOR    FILE,     IT    HAS 

M  A    HEADER    SHOWING    OWNER'S    NAME   AND    CURRICULUM 

235         REACH, 275)    Z,Y 

240         WRITE (6,242) ( IN(N),N=12,20),Z,Y 

242  F0RMAT(1X,9AI,«     IS    THE    SSN    LISTED    FOR    «,A8,'     OF    »,S 

•CURRICULUM     f,A8) 
CALL    CLOSE(l) 
GO    TO    100 

243  CALL  CLOSE(l) 
ii 

"       INSERT  (DELETE)  THE  FILE 

M 

245  CALL    REVISEIVECTOR, LENGTH, ENTRY(l) , ENTR Y( 2) , PTR, LEVEL,? 

I  NCR, LAST, ERROR, ENTRY(K)  ) 
IF    (ERROR. EQ.l)    GO    TC    100 
IF    (INCR.EO.O)     GO   TC    300 

"  CREATE    THE    NEW    FILE 

ii 

CALL    OPENl 1,ENTRY(K)  , 'OUTPUT'  ) 

WRITE(1,270)    ZERO 
270         F0PMATU4) 

IF    (LEVEL. EQ.l)    GO    TO    273 

BUF(1)=ENTRY(  1) 

BUF(2)=NAME 
273  KK=LLEN(LEVEL) 

WRITE  (1,275) (BUF( J) ,J=i,KK) 
275    FORMAT(IOAB) 

IF  (LEVEL. EO. 2)  BUFF=CLEAR 

CALL  CLOSE(l) 


ADD  FILE  TO  A  BACKUP  LIST  (CRLIST  OR  DLLIST) 

CALL  OPEN(l,LIST( I),fMOD» ) 

THING= BLANK 


MAKE  SURE  ALL  DIRECTORIES  HAVE  BEEN  REWRITTEN  BEFORE  STOPPING 
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IF  (LEVEL. EQ. 2)  THING=ENTRY< I) 
WRITE (1,280)  V( I), ENTRY (K! ,THI  NG,  VI  (  I  ) ,  NAM  E 
280    FORMA T(A4, IX, A8 , IX , A8, IX, A4, 1 X,A8) 
CALL  CLOSE(l) 

M 

••  ENABLE    DIRECTORY    REWRITE 

H 

300         COPY(LEVEL)=l 

I  R  UN= 1 
n 

"  GET    NEXT    COMMAND 

n 

GO    TO    100 

500         DO    550    1=1,2 
n 

•i 

M 

550  IF    (COPY(I).EQ.l)    CALL    LCAC( I , DUMMY, COP Y( I ) ,LAST, t 

VEC TOR, LENGTH, DUMMY, 0) 
•* 

••  IF    ANY    FILES    HAVE    BEEN    EDITED,    REQUEST    A    TAPE    COPY 

it 

IF    (IRUN.EQ.l)    WRITE(6,560) 
560         FORMATP    AFTER    JOB    ENDS — TYPE:       PUNN    COPY') 

STOP 

END 
ti 

•i 

N 
It 

M  RECOVR  EDITS  DIRECTORIES  AFTER  SYSTEM  FAILURE  TO 

"  CONFORM  TO  FILES  CRLIST  AND  DLLIST 

"  SUBPROGRAMS  INVOKED  BY  RECOVR  ARE  SHOWN  IN  THE  OLF  LISTING 

n 

INTEGER  LENGTH(3),ACT(2)/1,-1/,DUP,PTR,ERR,S 
C0PY(3)/3*0/,0K(2)/0, 1/ 

INTEGER*2  $$/•$$•/, A 

REAL* 8  VECTOR (260) , L AST (4) M* • DUMMY* /, DUMMY/' DUMMY • /, BLANK/'  •/,* 
LIST (2) /'CRLIST'  ,  'DLL  I  ST' / , ITEM1 ,1 TEM2, CURR IC/ • CURR I C / , FI LE 

EQUIVALENCE  (A, FILE) 

00  1000  1=1,2 

INCR=ACT(I ) 

IOK=OKU) 

CALL  0PEN(10,LIST(I)  ,' INPUT' ) 

DO  500  J= 1,10000000 

READ(10,10,END=1000)  I TEM2 , ITEMl ,FI LE 
10     F0RMAT(5X,A8,1X,A8,6X,A8) 

LEVEL=3 

IF  (FILE.EC.CURRIC)  LEVEL=1 

IF  (A.EQ.$$)  LEVEL=2 

CALL  L CAD (LEV EL, FILE, COPY (LEVEL), LAST, VECTOR, L ENGTH, BLANK , 0) 

IF  ( ITEMl. EQ. BLANK)  ITEM1=ITEM2 

C0PY(LEVEL)=1 

CALL  BISECTIVECTOR, LENGTH, ITEMl ,DUP ,PTR , LEVEL , LAST ) 

IF  (IOK.EQ.DUP)  CALL  REVIS E( VECTOR , LENGTH, % 
ITEMl, I TEM2,PTR, LEVEL,  I  NCR, LAST, ERR, FILE) 
500    CONTINUE 
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1000   CALL  CLOSEUO) 

DO  1050  1=1,3 
1050   IF  «COPY(LEVEL).EQ.l)  CALL  LCAOC I , DUMMY, 1 , LAST , VECTOR ,* 
LENGTH,DUMMY,0) 

STOP 

END 


COPY  IS  A  BATCH  JOB  WHICH  INVOKES  SEVERAL 
PROGRAMS  TO  CREATE  TAPE  COPIES  OF  OLF  FILES 
FOR  BACKUP  PURPOSES 

//*  ID   CARD  IMAGES  GO  HERE 

//  EXEC  TSBATCH 

//SYSIN  DD  * 

(PLORTS  LOGIN  INFORMATION  GOES  HERE) 

OPEN  CCOPY 

FORTRAN 

CLOSE 

RUNN  ID,C0PY1,SAVE,SLSTAR 

RUNN  ID,C0PY2,SAVE,SLSTAR,CELETE1,CLLIST,DELETE2 

LOGOUT 

/* 

M 

"       CCOPY  CREATES  A  FILE  (SAVE)  WHICH  IS  A  COMPOSITE 
"       OF  ALL  OLF  CATA  FILES 

n 

REAL*8    VECT0RC260) ,G  IB8( 5 ) ,DC ODE < 12 ) , NAMEI4) / • CURR IC ,3**     •/ 

REAL    GIB4U6) 

INTEGER*2  GIB2I20) ,CHEKOV( 12) ,HEA0ER( 32  )  ♦ DBLOCM 56 , 12 ) 

INTEGFR  PART(5,5)  ,L ENGTH I  3 ) ,L i< 3) / 1 ,201 ,24  I/, L3( 3)  /0,20,0/,S 
LEN(3) , ROWS/5/ 

CALL  OPEN( 10, •SAVE* , 'OUTPUT* ) 

CALL  OPENCl, 'DATES* , "INPUT*  I 

REA0I1,5)     I, J 
5  F0RMATC2I5) 

WRITE<10,5)     I, J 

CALL    0PEN(2, 'PART* ,•  INPUT*  ) 

REAC(2,10)((PART(  I, J  ),  J=l , 5 ) , I  =  1 ,ROWS) 
10  F0RMAT(5(U,1X)  ) 

WRITE(10,10){ (PART(I,J),J=1,5),I=1,R0WS) 

CALL    CL0SE(1,2) 

1  =  1 
12  LEN(I)=0 

CALL    OPEN( I,NAME(I), 'INPUT*  ) 

READ!  I,  15)    K 
15  F0RMAT(A4) 

WRITE(10,15)    K 

LENGTH(I)=K 

IF    (LENGTH(l) .EO.O)    CO    TO    80 

IF     (K.EQ.O)    GO    TO    60 
17  LEN( I)=LEN(I )+l 

IF     (LENII ) .NE.l)    GO    TO    22 

ISTART=L1(  I) 

IEND=L1CI )+L3(I J+K-i 
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REAC( 1,20 ) I  VECTOR (J)  ,J=ISTART,  IEND1 
20     F0RMATU0A8) 

WRITE <10,2  0M VECTOR! J), J=I START, IEND) 
22     NAME! I +1)= VECTOR (Ll( I)+L3( I)+LEN( I )-l) 

1*1*1 

IF  (I.LE.3)  GO  TO  12 

CALL   CLOSEtl) 

DO    40    J=ISTART,IEND 

CALL    OPEN!  I, VECTOR ( J ) , • INPUT* ) 

READ(1,25)    HEADER,GIB8,GIB4,GIB2,CHEK0V,DC0DE,DBL0CK 
25  F0RMAT(32A1,5A8/16A4/20A2,12A1/6A8/6A8/(28A2I  ) 

40  WRITE(10,25)    HEAOER, GI B8,Gl B4 ,GI B2 ,CHEKOV, OCODE, DBLOCK 

1=1-1 
60  1=1-1 

IF    (LEN(I).LT.LENGTHU))    GO    TO    17 

IF    (I.GT.l )    GO    TO    60 
80  CALL    CLOSE(1,2,3,10) 

WRITE(6,100) 
100         FORMAT!*    ALL    FILES    PREPARED    FOR    COPY*) 

STOP 

END 
it 

n 
it 
•• 

ID  IS  A  PLORTS  FILE  CCNTAINGING  ID  CARD  IMAGES 


C0PY1  AND  C0PY2  ARE  PLORTS  FILES  CONTAINING  CARD  IMAGES 
WHICH  INVOKE  THE  CATALOGUED  PROCFDUPE  COPY.   C0PY1 
CREATES  A  COPY  OF  THE  FILE  SAVE  ON  THE  FIRST  BACKUP 
TAPE,  C0PY2  CREATES  A  COPY  OF  SAVE  ON  THE  SECOND  BACKUP 
TAPE.   DUPLICATE  COPIES  PREVENT  THE  DESTRUCTION  OF 
THE  BACKUP  SYSTEM  BY  A  SYSTEM  FAILURE  DURING  PREPARATION 
OF  A  NEW  BACKUP  TAPE 

COPYl: 

/♦SETUP  UNIT=TAPE,ID=02725  5,RING 

//  EXEC  COPY 

//SYSUT2    DO    DSN=LERNER.P6416. COPYl, DISP=(NFW, KEEP), UNIT=TAPE, 

//  VOL=SER=027255,LA8EL=(2,SL), 

//        DCB=<LRECL=80,BLKSIZE=3  200,RECFM=FB) 

//SYSUT1  DD  * 

C0PY2: 

/♦SETUP  UNIT=TAPE,ID=027310,RING 

//  EXEC  COPY 

//SYSUT2  DD  DSN=LERNER.P6416.C0PY2,DISP=(NEW,KEEP) ,UNIT=TAPE, 

//        V0L=SEP=027310,LABEL=(1,SL), 

//        DCB=<LRECL=80,BLKSIZE=3200,RECFM=FB) 

//SYSUT1  DD  * 
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SLSTAR  IS  A  PLDHTS  FILE  CONTAINING  THE  CARD  IMAGE:  /* 


OELETE1  STARTS  A  NEW  JOB  STEP  TO  DEALLOCATE  OBSOLETE 

FILES.   AFTER  THE  BACKUP  HAS  BEEN  MADE  AND  THE  DEALLOCATION 

LIST  HAS  BEEN  USED,  SAVE,  CRLIST,  AND  DLLIST  ARE  ALL  OBSOLETE 

//  EXEC  TSBATCH 

//SYSIN  DD  * 

(PLORTS    LOGIN    INFORMATION    GOES    HERE) 


DELETE2    DOES    THE    FINAL    DEALLOCATION    AND    A    LOGOUT 

DEST    CRLIST 
DEST    DLLIST 
DEST    SAVE 
LOGOUT 
/* 


RESTORE    IS    A    BATCH    JOB    WHICH    USES    TWO    PROGRAMS    TO 

RESTORE    OLF    FILES    TC    A   TIME    BEFORE    A    SYSTEM    FAILURE. 

THE    BACKUP    TAPE    CREJTEC    BY    COPY    IS    USED    FOR    THE    RESTORATION 

//*       ID    CARD    IMAGES    GO    HERE 

/♦SETUP    UNI T=TAPE, ID=0272  5 5, NOR  I NG 

//    EXEC    FILE,PAPM=»6416,LERNERI 

//SAVE    DD  DSN=LERNER.P6416.C0PY1,DISP=(SHARE,KEEP),UNIT=TAPE, 

//        VOL=SER=027255,LABEL=(2,SL) 

//SYSIN  DD  * 

DD=SAVE,PRINT=YES 

/* 

//  EXEC  TSBATCH 

//SYSIN  DD  * 

(PLORTS  LOGIN  INFORMATION  GOES  HEREI 

0  RECOPY 

FORTRAN 

C 

LOGOUT 

/* 


RECOPY  READS  A  FILE  (SAVE)  WHICH  IS  A  COMPOSITE  OF  ALL 
OLF  DATA  FILES  AT  SCME  EARLIER  TIME,  AND  RECREATES  THE 
THE  INDIVIDUAL  FILES 

REAL*8  VECT0RC260)  ,CCODE(  12  )  ,  NAME  14  )/ •  CURRICSS**  •/,% 
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GIB8(5) , BLANK/'     •/ 

REAL    GIB4<16) 

INTEGER*2    HEADER! 32 ) ,CHEKOV ( 12 ) , GI B2 (20 ) , DBLDCM 56, 12 > 

INTEGER   R0WS/5/,PART<5,5) .LENGTHC 3 ) ,L1 ( 3) /l ,201 ,241/ ,L3( 3) * 
/0,20,0/,LEN<3l 

CALL    OPEN(  10,  •SAVE*  ,'INPUT'  I 

CALL    OPEN( 1, 'DATES*, 'OUTPUT* ) 

REA0(10,5)     I( J 
5  F0RMAT(2I5) 

WRITE(1,5)     I, J 

CALL    0PENC2,' PART' , 'OUTPUT • ) 

READ! 10, 10) ((PART (I, J)  ,  J=l  ,  5) ,  1  =  1 ,  ROWS) 
10  F0RMAT(5(Il,lxn 

WR I  TE  (  2  ,  10  M  (  P  ART  (  I  ,  J )  ,  J=  1 ,  5  ) ,  I  =  1 ,  ROW  S  ) 

CALL    CLDSE(1,2) 

1  =  1 
12  LEN(I)=0 

CALL    OPEN(I,NAME(I ), 'OUTPUT' ) 

READ(10,15)    K 
15  F0RMATU4) 

WRITE! 1,15  )    K 

LENGTH(I)=K 

IF    (K.EQ.O)    WRITE(I,20)    BLANK 

IF     (LENGTH(l).EQ.O)    GO   TO    80 

IF     (K.EO.O)    GO    TO    60 
17  LEN(I)  =  LENU)+i 

IF     (LEN(I).NE.l)    GO    TO    22 

ISTART=L1( I) 

IEND=L1U  )*L3(I)+K-1 

RE AC (10,20) (VECTOR (J ) , J=I START , I  END ) 
20  F0RMAT(10A8) 

WRITE (  I,20)(VECT0R(J),J=ISTART, I END) 
22  NAME(I«-1)  =  VECT0R(L1( I)+L3( I)+LEN(I)-1) 

1=1  +  1 

IF    (I.LE.3)    GO   TO    12 

CALL    CLOSE(l) 

DO    40    J=ISTART,IEND 

CALL    OPEN( 1,VECT0R(J), 'OUTPUT' ) 

RE AD (10,25)  HEADER,GIB8,GIB4,GIB2,CHEKOV,0CODE,DBL0CK 
2  5     FORMAT(32Al,5A8/16A4/20A2, 12 A I /6A8/6 A8/ ( 28 A2) ) 
40     WRITE(i,25)  HEADER , G  IB8 ,GI B4,GIB2 ,CHEKOV, DCODE ,DBLOCK 

1  =  1-1 
60     1=1-1 

IF  (LEN(I ).LT.LENGTH(I) )  GO  TO  17 

IF  (I.GT.l)  GO  TO  60 
80     CALL  CLOSE(l,2,3,10) 

WRITE(6,100) 
100    FORMATC  FILES  ARE  NCW  RESTOREO') 

STOP 

END 
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